Internal routing precedence of broad iroute overshadowing a server’s own local subnet within OpenVPN’s internal routing algorithm

In a situation where there is

• a local network, e.g. 172.16.11.0/24 attached to the server system and
• broader network, e.g. 172.16.0.0/12 shall be routed to a specific OpenVPN client, so
• route 172.16.0.0 255.240.0.0 is specified in the server config and corresponding iroute 172.16.0.0 255.240.0.0 in the client's CCD file,
  the OpenVPN internal routing violates the longer-prefix rule and routes packets for 172.16.11.0/24 to the specific client instead of to the local server system.

To Reproduce
Add a broader route to the server config that corresponds to a local network behind the server, that routes the packets (back) to a client and then try to reach the local network behind the server from the client.

Expected behavior
Longer-prefix rule is observed, local network behind the server is reachable.

Version information (please complete the following information):

• OS: Debian 12.11
• OpenVPN version: 2.6.3

A warning that an internal OpenVPN route overlaps a local route would be helpful.
A server-side "iroute" which would add a local route to the OpenVPN Server's internal route without adding it to the kernel routing table would fix this as well, but AFAICU it would be good and better if OpenVPN internal routing would respect the longer-prefix rule.

Start by reproducing the described server and client configuration on OpenVPN 2.6.3 with a local 172.16.11.0/24 network and broader 172.16.0.0/12 iroute. Trace the internal routing selection to determine why the broader route wins, then verify that the longer-prefix local route is selected and consider the requested overlap warning.