1. Make ICMP reject messages originate from the triggering packet's incoming interface IP instead of the first configured one.
2. Keep the connection mark of the triggering packet on the ICMP reject mesage.

This will allow us to send the proper ICMP message back the way it came in.
At the moment, it seems that the IP of the first configured interface is used for ICMP rejects, and no connection mark is applied to this ICMP response to an incoming packet matching a reject rule. This means that the ICMP will follow the routing of that first interface, not the one of the packet that triggered the reject.

I think it is the /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr setting of the Linux kernel.
This normally governs the "originate from the triggering packet's incoming interface IP" part.
However, it also states that this fails "when the interface has no primary IP address", in which case
the address of the first interface is used.
It occurs to me that in a MikroTik, while you can define many IP addresses for an interface, there
is no way to set the primary address. Maybe this is not done, and therefore the above setting
cannot do its job.
See Documentation/networking/ip-sysctl.txt in the Linux kernel docs.

Could be. In my case the incoming interface is a tunnel has a single IP and is in a vrf (i think you know the scenario ). That means I have to mangle the routing mark and add a connection mark to get the packets into the main routing table (and responses back to the proper interface).
Now if I have a some reject with 'network not reachable' in the main table, instead of getting an icmp originating on that incoming interface IP, I could mangle it back to the proper interface based on the connection mark (which is also not there) or at leased based on src and dest. But instead I will push an icmp via the default route to the internet, which could be meaningless if the originator is not reachable via that public path.
Of course I can mangle the output to go out via the tunnel, but the source IP is invalid for that tunnel.

Fortunately our big internet-hamnet gateway is not a MikroTik but a plain Linux box where I can solve
issues like this (and others).
We use MikroTik only internal to the network, so we did not yet encounter these issues I think.
But I am not so sure, see the problem I posted in General with updating MikroTik firmware from the
WebFig. Because part of the path has smaller MTU than 1500, it is important that the public internet
webservers get the correct ICMP "unreachable" replies. I think they do, but still it does not work!
I cannot find out if this bug is in our gateway or in the MikroTik servers (too agressive firewall dropping
our ICMP or rate-limiting them too heavily?)