There does not appear to be a direct equivalent.
[27927.296390] XFS (sdb4): Mounting V5 Filesystem
[27927.869545] XFS (sdb4): Ending clean mount
[27942.761564] usb 2-2: USB disconnect, device number 31
[27943.011211] usb 2-2: new full-speed USB device number 32 using xhci_hcd
[27960.810143] XFS (sdb4): Unmounting Filesystem
[27960.811247] XFS (sdb4): metadata I/O error in "xlog_iodone" at daddr 0x58b10a len 64 error 5
[27960.812077] XFS (sdb4): xfs_do_force_shutdown(0x2) called from line 1271 of file fs/xfs/xfs_log.c. Return address = 00000000758bdd7c
[27960.812708] XFS (sdb4): Log I/O Error Detected. Shutting down filesystem
[27960.812728] XFS (sdb4): Unable to update superblock counters. Freespace may not be correct on next mount.
[27960.813349] XFS (sdb4): Please umount the filesystem and rectify the problem(s)
[28509.842965] sdb: sdb1 sdb2 sdb3 sdb4
[28509.846156] sd 2:0:0:0: [sdb] Attached SCSI removable disk
[28517.755990] XFS (sdb4): Mounting V5 Filesystem
[28518.328431] XFS (sdb4): Ending clean mount
file -s /dev/sdb4 is able to show when an ext4 filesystem "needs journal recovery", but it does not detect any difference when I test an uncleanly unmounted XFS filesystem.
xfs_repair does not show any difference either. In fact, the list of common messages in
man xfs_repair do not include anything about journal replay. Instead:
The xfs_repair utility cannot repair an XFS file system with a dirty log. To clear the log, mount and unmount the XFS file system. If the log is corrupt and cannot be replayed, use the -L option ("force log zeroing") to clear the log, that is, xfs_repair -L /dev/device. Be aware that this may result in further corruption or data loss.
While ext4 maintains special flags to indicate an unclean unmount, it sounds like XFS only maintains the journal. If the journal is empty then it is "clean"; there is nothing to repair/recover/replay.
(If your OS wishes to detect unclean shutdowns, then it must do so itself, like Windows does :-).