Hi and thanks generous comment from everyone~
I found the temporary work around and it works great since last night: generate 40 native bech32 addresses and save it as .png., replace bitcoin:BC1q*** QR photo with what each .png file actually says bc1q**** with .png / .jpg generated from another QR code generator. merge 4 of those unique bech32 request payment QRs and Print them out + cut it up nightly to have 40 unique wallet address for the next morning. took me bet. 10-15 minutes for all this.
Then on 10xA4 sized paper @ with 4 native bech32 addresses with modified QR image with correct lower case bc1q*** encoding.
You should avoid using such tools that can not process upper case bech32 addresses because that is a bug in their implementation as the said encoding is not case sensitive and should only reject mixed case strings.
^We have no control: Neither our establishment nor street food vendors renting space at lobby / courtesy areas selling rice balls (飯糰), fish balls, or soy milk had much say on which wallet tourist / bitcoin user should use. Maybe across the straight in mainland China is better@mandate things - for example: either use compliant wallet like Muun to receive
BTC or be outright banned.
The "tool" we use is bCore 23. What is odd about it is when operator press "Create new receiving address" what the QR shown on screen along with code (lower case) don't match what QR really is. Since no one wants to wait for confirmation with lowest fees when merchant received some payment unconfirmed on modified QR image wallet we have script that analyzes it to make sure transactions are ledgit. If not screening Bcore node LINE vendor directly with txt description of potential issues so they can bring it up with bitcoin sender in seconds.
can't seems to get BCore 23 to put out images that matches what encode on the QR.
The QR really says bitcoin:BC1q****<SNIP>. we have to instead find another in-house quick-fix ASP.NET app to re-encodes saved .png it into bc1q****<SNIP> and all problem went away.
There should not be any workarounds available since the whole point of designing bech32 encoding like this was to allow QR codes to be created using upper case letters as @nc50lc pointed out.
^ our 40 bech32 address work around QR image on paper @day seems rather equitable for now, until a more permanent solution similar to cypherpunkpay.org (not perfect) that works behind RFC1918 closed network being fully implemented.
I guess we'll just have to take those 25, 30, 45NTD payments more than once from different non-compliant wallet users on the same lower case bc1q paper wallet when we ran out (you know, some bitcoin-er travels in group. we have no control of that either)
To put in perspective mining fees for each incoming is approx 45NTD (approx $1.45) for non-native segwit alternative. For room reservation/checkouts that is fine, but for those vending joints in the lobby native segwit becomes significant: breakfast costs 85-120NTD on average, but those problematic native segwit users pays 5-10NTD(~$0.25) minimal fees. Maybe I'll exploit better alternative with bc1p addresses to make direct bitcoin payment effective. There are alternatives, of course (LINE Pay, 旺 PAY, or YoYoPay 悠遊付 merchant integration).
Then there are incoming LN payments as well but settle fund out of it daily for accounting seems rather expensive. Freedom isn't cheap - even A4 paper prices are out of control.
