I think meshtastic would be a lot more performant in mesh scenarios due to the added range of LoRa. But of course it's special hardware and thus suspicious during an insurrection. And probably just not available.
I doubt this will actually work though except in the densest city.
Meshtastic also struggles with high density and high traffic networks. Some modifications can be made to work better, but with the default settings it really grinds to a halt, and modifying the settings to be better suited requires some expertise and foresight. It works amazingly in off grid, relatively sparse networks, but it's got some major limitations.
Yeah I always wonder with these mobile ever changing mesh networks: how do they prevent messages from aimlessly looping around the network? With all the mobile devices they're too dynamic to make routing tables and broadcasting everything leads to network saturation really quickly. You could give them a very short TTL but then the reliability will suffer a lot.
Meshtastic has a TTL of up to 7 and (from what I've been able to understand) uses flood routing largely. In Northern Colorado (where I'm at) we don't have a particularly dense mesh, but are turning down from 7 because of congestion.
Meshcore seems to (I'm still learning on this) use a TTL of 64 and flood to find a route to a destination, then uses source routing for future packets, reverting to flooding again if that path fails (say a mobile repeater moves out of range).
The decision that every station is always a (delayed) router was a bad one. Also the old firmware was super chatty eating a lot of valuable ISM TX time.
They must clean up their role mess and switch to a "all clients are totally quiet - until they are set to a different mode for a reason"-strategy.
Eh, Meshtastic was originally for sparse off grid comms less than big public networks. In that role (which is still what I mostly use Meshtastic for) every client repeating messages makes more sense.
I doubt this will actually work though except in the densest city.