Potential bug: Inconsistent next-hop resolution in multi-homed same-subnet setup

[HaoRanLiu]

Hello,

I am writing to report a potential issue (or seek clarification on 
resolution logic) in BIRD 2.17.1 regarding how next hops are resolved 
when multiple interfaces exist in the same subnet.

[ Environment ]
- BIRD version: 2.17.1
- OS: Linux
- Setup: Multiple physical interfaces (ens4, ens23, ens2) are configured 
with IP addresses in the same prefix: 203.163.222.0/23.

[ Observation ]
Within a specific routing table (table_tpix_210440_v4), BIRD's recursive 
resolution for a BGP route does not seem to honor the "Direct/Device" 
route present in that same table.

[ Evidence ]

1. The Direct Route in table "table_tpix_210440_v4" points to ens4:

bird> show route for 203.163.222.39/32 table table_tpix_210440_v4 all
Table table_tpix_210440_v4:
203.163.222.0/23     unicast [direct_tpix_210440 2026-01-11 21:10:29] * 
(240)
         dev ens4
         Type: device univ

2. However, a BGP route in the SAME table resolves via ens23:

bird> show route for 1.1.1.1 table table_tpix_210440_v4 all
Table table_tpix_210440_v4:
1.1.1.0/24           unicast [cloudflare_tpix_210440_v4 2026-01-11 
21:33:43] * (100) [AS13335i]
         via 203.163.222.39 on ens23
         Type: BGP univ
         BGP.origin: IGP
         BGP.as_path: 13335
         BGP.next_hop: 203.163.222.39
         ...

[ System Network State ]
The OS kernel shows three interfaces in this subnet:

# ip route show 203.163.222.0/23
203.163.222.0/23 dev ens23 proto kernel scope link src 203.163.223.49
203.163.222.0/23 dev ens2 proto kernel scope link src 203.163.223.50
203.163.222.0/23 dev ens4 proto kernel scope link src 203.163.223.48

[ Questions ]
1. Is this a bug in the recursive resolution logic? It appears BIRD 
might be picking an interface from the global interface list (perhaps 
the first one UP) rather than following the best route available in the 
specific table being queried.
2. Why does the BGP route's "via" field not honor the interface (ens4) 
defined by the device route in the same table?
3. Is there any configuration to force BIRD to resolve next hops 
strictly based on the current table's best path in such multi-homed 
scenarios?

Any insights would be appreciated.

Best regards,
Liu HaoRan