EDIT: Whops for some reason I never got a notification for the other thread and did not see your answer. As I describe in this post below, I think this works much simpler, without macvlan interfaces.
I could swear I tried this (and all other combinations, including and excluding interfaces)
Having said that, I found a much nicer method that works completely without the macvlan hack. I'll document it here for everyone looking for the same.
It seems for crossing VRF, when the target is on the same router (and possibly? both not main VRF), the following is sufficient:
# ordinary static route leak from vrf-main to vrf-as (response route)
/ip route
add disabled=no distance=1 dst-address=192.0.2.208/28 gateway=\
vlan44@vrf-as routing-table=vrf-main scope=30 target-scope=10
# Special /32 routes (forward route)
/ip route
add comment="XVRF: Access services@vrf-main from vrf-as" disabled=no distance=1 dst-address=10.2.4.2/32 gateway=vrf-main@vrf-main routing-table=vrf-as scope=30 target-scope=10
add comment="XVRF: Access services@vrf-main from vrf-as" disabled=no distance=1 dst-address=10.2.4.254/32 gateway=vrf-main@vrf-main routing-table=vrf-as scope=30 target-scope=10
In this example, 10.2.4.2 is the IP address of the router which is from an interface inside vrf-main which should be accessible from vrf-as (e.g. from network 192.0.2.0/24). 10.2.4.254 is a VRRP address.
Probably a firewall rule is required to allow traffic to flow. For example, to access Mikrotik's DNS server in vrf-main from vrf-as:
/ip firewall filter
add action=accept chain=forward comment="XVRF: Allow dns access from vrf-as" dst-port=53 out-interface=vrf-main protocol=udp src-address=192.0.2.0/24
This really is it! 
Now an added bonus is having the service (e.g. DNS) also available on a router owned address from vrf-as, for example, 192.0.2.210. It took me a while to get this working properly. The trivial part is to set up a DNAT rule. But the non-trivial part is to make sure that the return packets are immediately routed to the right routing table, otherwise DNAT is looked up twice and the TCP handshake succeeds but following packets all time out. Extremely nasty issue to debug!
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=192.0.2.210 dst-port=53
in-interface-list=MY_PREFIX protocol=udp src-address=192.0.2.0/24 to-addresses=10.2.4.254
/ip firewall mangle
add action=mark-routing chain=output comment="XVRF PortFW: dns" new-routing-mark=vrf-as out-interface=vrf-as protocol=udp src-port=53
Now being super excited that this is working more elegantly, I am not able to get dynamic inter-VRF route leaking (via bgp vpn) working and by now I'm fairly confident this must be a regression/bug in RouterOS. Have you ever used /routing/bgp/vpn for dynamic VRF route leaking in the past and was it working?