Bech32 standardization

[BrendanBenshoof]

So bech32(and bech32m) is a really well thought out encoding but it's specification and implementations are tightly bound with bitcoin's use cases.

I think @FiloSottile made a really good choice in using it for age and I'd like to use it in the future for my own projects.
I'm not interested in keeping my implementation bound to bitcoin's spec, our goals and incentives are poorly aligned.

Concerns:

• age needed it's own implementation of the format to use it effectively.
• age (and every other implementation I have seen) don't actually use the error correction aspect of BCH encoding
• bech32 has length limitations driven by it's checksum method.

Proposal:

• Establishing a new specification that cites and gives credit to the BIPs but also specifies bech32 without the context of Segwit addresses
• Extend the spec to handle longer values encoded, including handling of checksums at longer lengths
  • This may require a non-backwards compatible change, because the fixed length of the checksum is currently used to determine the payload length
• Give this spec a new name ("bech32a" comes to mind, but I'm not attached to it)
• Establish an implementation reference in commonly used languages (including optional error correction)

I'm happy to do this work myself, but I would rather coordinate, communicate, and seek review with y'all about it vs just posting a spec I made up.

I think the major design decisions I'm seeking input on are:

• how to we handle longer lengths and checksums?
• what do we name it?

[BrendanBenshoof]

It doesn't look like there is interest in this.