That is a really interesting case. VRFs, WireGuard sockets, conntrack, and NAT together can create some very unexpected behavior on RouterOS.
One thing I would look at is separating the service endpoint from the VRF routing domain for example using a dedicated loopback/service address and controlled route leaking rather than trying to make the same WireGuard listener behave across multiple VRFs. Locally generated WireGuard replies can behave differently from normal forwarded traffic, which makes these scenarios tricky.
This type of problem is actually one of the reasons we built TunGuard. Not because WireGuard itself is difficult, but because once you add real-world requirements like multiple sites, NAT, CGNAT, provisioning, remote access, and migrations, the operational side becomes the hard part.
TunGuard takes a different approach: userspace WireGuard engine, automated peer management, MikroTik provisioning, and an optional SSH jump host for remote access.
If you are interested, the project is here:
https://mikrotik-provision.vercel.app
Would also be interested to hear how you ended up solving this VRF design.