As far as I can see RFC9234 does not mandate handling a route leak with Treat-as-widthdraw. It just refers to leaking routes to be ineligible (for further use).

My understanding: a leaked route should be present in Adj-RIB-In, but not into Loc-RIB.

I do understand that Bird does not follow the traditional path of other BGP speakers and has no Adj-RIB-In/Out. In a multi-table route server setup Adj-RIB-In/Out is mimicked by the per-peer-table. In a single-table setup, the leaked route would go into the main table.

So the question is: Could you imagine another way (i.e. different from Treat-as-withdraw) of handling "ineligible" routes?

import table switch

A BGP import table contains all received routes from given BGP neighbor, before application of import filters. It is also called Adj-RIB-In in BGP terminology. BIRD BGP by default operates without import tables, in which case received routes are just processed by import filters, accepted ones are stored in the master table, and the rest is forgotten. Enabling import table allows to store unprocessed routes, which can be examined later by show route, and can be used to reconfigure import filters without full route refresh. Default: off.