That brings me to Matt's point: there is no need to do this right now. We can simply amend BIP173 to only permit length 20 and length 32 (and only length 20 for v0, if you like; but they're so far apart that permitting both shouldn't hurt), for now. Introducing the "new" address format (the one using an improved checksum algorithm) only needs to be there in time for when a non-32-byte-witness-program would come in sight.
This means we could safely allow witness programs of lengths 20, 23, 26, 29, 32, 36, and 40 (or 39). These correspond to Bech32 addresses of length 42, 47, 52, 57, 62, 68, and 74 (or 73). We could also support a set of shorter addresses, but given the lack of entropy in such short addresses, it is hard to believe that such witness programs could be used to secure anything. I'm not sure what the motivation for allowing such short witness programs was, but I'm somewhat inclined to exclude them from the segwit address format.
Given that we would only be able to support one of 39 or 40 byte witness programs, it is sensible to choose to allow 40 byte witness programs to be addressable. This is the maximum witness program size allowed by BIP 141.
So my proposal would be to amend BIP173 in such a way to restrict "bc" and "tb" segwit address formats to require witness programs be of size 20, 23, 26, 29, 32, 36, or 40. Witness programs of other sizes (between 2 and 40) would, of course, still be legal in accordance with BIP 141; however they would be unaddressable by using this "bc" and "tb" prefix. Another address format would be needed to support other witness sizes, should the need ever arise.
--
Russell O'Connor