Ok. The only part I was wrong is the minutia about is how it double-nats. NDIS does, not MBIM. But, whatever... as it's not really important. There was a valid reason for me not running a Quectel modem on any Openwrt equipment in MBIM mode, and I tested it again and re-discovered what it is:
There is a serious problem. The Quectel modem and SIM (verizon in this case) only works in QMI (AT+QCFG="usbnet",0) mode, if NO APN and NO MTU is configured.
That happens with two different manufacturer's devices and two different quectel modems, different models, both, entirely. One is a Cat6 with no CA and another is a Cat18 with CA. One router is a GLINET, one is a NETGEAR. It's probably the garbage hardware and software inside the quectel, actually causing the issues, but here's the issues related to Openwrt functioning with it:
If you use QMI, and do not set anything, and just let it connect, it works. It's stable. But MTU is 1500, and the interface has no way to detect it. It should be 1428 - or, whatever size you want. 1428 - it's all over online, and well-known as a value. But, when you set the MTU, the connection, while it starts out very smooth and fast because now the MTU is correct, it quickly becomes very unstable; the shtty quectel garbage locks-up, the router needs to be rebooted. Expect a connection to last some minutes, not days, with the MTU set. Unset the MTU, reboot, and it goes back to normal.
Do NOT set the APN, either, or similar bad behavior occurs. The modem will pull the correct profile automatically from the SIM, and setting the APN makes it not work correctly.
MBIM: If you switch the modem to MBIM (AT+QCFG="usbnet",2), and setup the MBIM wwan0 device, it works great - at first. It does autodetect the MTU, as 1428. That's the greyed-out field in the box under Advanced Settings, telling you it's the default (unlike QMI which says 1500). However, you cannot not set an APN and enable the adapter/interface. Openwrt will not permit you, through Luci, to leave it empty. I did not try through the shell, directly.
And soon, you get PIN errors - but the sim has no PIN requirement. And NO CARRIER etc all kinds of errors attempting to connect. At first, with MBIM, it works for a few minutes, nice and smooth, but then it fails. When I retested all of the above, over the last several days, on the LBR20 with it's EG18-NA, I remembered all the problems I had with the GLINET GL-X750 and it's EC25-AF (Cat6 no CA), and the experiences were the same. I thought it was the GL-X750 itself, at first, but the more I experienced, and talked with people who had thousands of Quectel modems in devices they were in technical departments overseeing, the more I got the feedback that they are garbage. Something licensed from Qualcomm, that the staff at Quectel just fabs out, but has little expertise in making them work right. Like that fake car part that doesn't fit right, or perform well, but looks similar to the OEM. It's not that that area of the world can't make quality stuff, it's just that Quectel is an example of a company staffed with people who don't.
Meanwhile, the question is how can the Openwrt device work around such garbage? Is there a way to make a custom build with MBIM that does not require input of an APN? I'm even considering just putting another router after the LBR20, like an MX4300, and setting the MTU on it's wan interface, since setting the MTU directly on the device with the Quectel, causes the Quectel interface to crash.
P.S. sites like test-ipv6.com correctly report that large packets are not being handled correctly, and the MTU should be set (on the wwan). Besides all the obvious speed / performance improvements in the brief periods when it was.