Why not expand the capability of Freifunk to work on more channels, and include neighborhood detection based on BSSID readings, where all BSSIDs are used, not just those belonging to the mesh?

AFAIK the main issue there is that common firmware lacks support for multiple simultaneous connections using the same radio but different channels. The system would need to negotiate time slots between the channels, as a single radio can't be active on more than one channel, while all channels can be active in the same collision domain simultaneously.

Note that this is not just to prevent multiple senders to co-occupy a single channel as CSMA/CA does, but to prevent a receiver listening to another channel or sending to another channel during the transmission. That way the packet would just be 'lost'.

For meshes of sufficiently small size, they could also buffer packets of higher-throughput links through the mesh (defined by whether the following optimization is worth it, or if it should just use regular, BATMAN-adv style, packet passing towards the destination during the time slot for general nodeA to nodeB traffic), and negotiate explicit bandwidth for them, possibly making use of multi-path intra-mesh routing if necessary to prevent buffer backlog and unutilized bandwidth on a path between the nodes this buffer held traffic for. This might be done in a hierarchical fashion, to only consider area targeting during the calculations for intra-node traffic, or, perhaps use e.g. raft/paxos to map between mac addresses and small integers, in order to reduce the size of communication necessary for telling other nodes about the amount of data in pending buffers.
Nodes would use PHY-broadcasting to their neighbors, which would then be followed by the receivers sending ACKs on a negotiated/inferred timeslot-raster, to prevent unnecessary airtime utilisation. Nodes would set their bitrate during those broadcasts to be just enough for those neighbours to receive which even need the data, potentially using unicast if the other neighbours don't need it. Receivers could infer their ACK time slot from the data, which would ensure that the whole ACK raster is just as long as needed.
Nodes could possibly aggregate this data (which btw consists of source, target, length-prefixed bytecount (where the latter would sacrifice the first 3 bits of the first byte holding the bytecount to denote how many bytes will follow, and source/target having just as many bits as necessary to represent the maximum ID as negotiated by raft/paxos) and is therefore to be decoded with bit-offsets) over multiple cycles, to reduce the overhead of sending one such block. They would have to wait no longer than (max_aggregation ratio * longest_path), or just kick a downstream node out of this round of discovery, if transmission to it fails more than a pre-defined number of retries. This is to ensure that all nodes of the mesh that send on the mesh-channels agree on what traffic will flow.

This would include data without ACKs stuck on intermediate hops.
If the data is too small for an individual link, it could either be shared with the negotiation step, or for purposes of negotiation it could be counted as "towards a region (measured by node's vicinity)", where those regions would be periodically defined via raft/paxos and allocated IDs out of the same range as nodes. This periodic definition should include tallies of recent data flows, possibly by just periodically transmitting a non-grouped view of dataflows between nodes, aggregated over the time since the last one. User-data forwarding and management communication could easily be interleaved, in order to reduce the delay for small, persistent channels (as something like VoIP could easily be seen as a constant stream of data and, properly QoS tagged, retransmits could be handled by the network more aggressively than usual, at a cost of higher actual bandwidth due to e.g. a lower bitrate being chosen (SNR), or some retransmits being figured in), as well as the impact of inherent delay figures of the process-and-forward bandwidth negotiation on a node's utilisation during that time. It should be possible to find a way around time slot allocations being unused due to the dynamic process of bandwidth negotiations not playing well with the fixed allocations necessary for using more channels with a node than it has channels.

If I didn't have better to do, I'd probably consider dabbling into this a little deeper, probably with ath9k devices (AR9280 seems to be a good candidate) and the open-source baseband, but I've allocated the time for other open-source things.