I agree with your proposal to use bech32 instead of base58. It looks sound to me and as you said, the standard would benefit from more compact QR codes.
The most important thing to get more compact QR codes is to not use lowercase letters, and certain other characters, as if you can avoid them the QRs will auto-compress.
It happens that the core of bech32 works if all caps, and you are careful with the human readable portion.
We have a number of standards & libraries focused on bitcoin QRs, including support of animated QRs for things like PSBTs, but if you care about QR size you should take a look at the techniques we use our swift library
https://github.com/BlockchainCommons/QRCodeGenerator which are also in
Basically both of these libraries support “optimal encoding using segments” that if they encounter a set of characters that must be encoded in binary (In particularly $ % * + / :) that would in most default platform QR implementations cause the entire QR to double in size. Instead will only encode the small segment as binary, letting the rest of the QR leverage auto-compression.
If your are interested in our other Airgap QR and TorGap UR efforts, see our video from last year:
I’d love to see proposals for various payment and invoice QRs that leverage these wallet interoperability standards we have been offering. Let us know if you are interested, or join discussions at
— Christopher Allen, Blockchain Commons