Yes, can confirm this here, and that it’s resolved by 6.19.5-1.
Workaround:
- Edit kernel cmdline, add
systemd.unit=rescue.target - Login to root shell and disable nftables:
systemctl disable nftables.service - System should allow booting until upgrade is possible
(or just runpacman -Syuin rescue shell to upgrade kernel)
Can also confirm that mdadm 4.5-2 resolves the RAID issue. Luckily for me, the system was not booting off RAID, but rather mounting RAID user data volumes. Thus, the workaround was to comment out the appropriate /etc/fstab lines, then boot & upgrade mdadm to 4.5-2.
For rescuing bootable RAID, booting into an alternate Linux dual boot install or LiveCD/USB would allow assembling the array, chroot-ing into the volume, and then upgrading mdadm via pacman (and probably also sudo mkinitcpio -P to update mdadm inside initramfs or UKI)
Finally, there is also a separate userspace nft rule loading issue. Rules adding multiple non-mutually exclusive (overlapping) IP address ranges to be merged into a single set fail to load. This is a regression, as this was working before, and is commonly done (e.g. by aur/nftables-geoip-db or similar GeoIP sets). The fix for this is here, but is not yet cherry-picked into Arch Linux PKGBUILD. 
Watching that one, as it blocks GeoIP firewall rules and other complex IP sets from working.