For a mesh this information gathering step can not be circumvented. Even if we change routing protocols, you still need to know your peers BEFORE being able to set up BGP or OSPF. And if you know your peers, you can know their subnets, too. So there is actually no need for a routing protocol running on a limited bandwidth network, because the information is already there, in your peering data.
Way back in the days of the previous packet radio network and NETCHL I started to code a solution for this. I implemented multicast in NETCHL and created a simple info protocol that multicasted information about the local system to address 224.0.1.31 port 1535 (look them up in DNS and /etc/services!)
These announcements were sent with a TTL of 5 or so, so the neighborhood in the then existing IP/AX.25/NETROM network learned some details about the nodes, like the sysop call, the frequencies it was operating on, and the subnets it was serving. The info could be displayed when connected to the NETROM.
The intention was to create an automatic IP routing protocol from there, and then replace IP-over-NETROM and plain connects over NETROM by an automatically routed IP network and a service to encapsulate plain user AX.25 connects (user1-node1-node2-user2) in TCP/IP connects between the nodes. (replacing NETROM)
This never materialized, and in neighboring Germany a network was deployed (Flexnet) that stuck to the AX.25 routing, and it became quite popular. The author was not interested in IP at all. More and more operators wanted to switch to that network so further development on NETCHL was mostly halted.
Of course, now this change has been made anyway (the network is IP with AX.25 running on top of it instead of under it), but quite some time has passed...
Of course we could again embark on such a project, but there is always the issue of migration to a new method without breaking the whole network in the transition phase.
Rob