The Quectel cards are ready to use immediately, they don't need switching.
They do however need operating system drivers and I doubt FreeBSD has them.

Thanks for the report and fix, Josh will take care of this obvious bug when he gets back.

Sorry, my post was maybe a little bit ambigous. My adapter (part of a multiport adapter) had the initial id of 0bda:8151 Port 1: Dev 3, If 0, Class=Mass Storage, Driver=, 12M ID 0bda:8151 Realtek Semiconductor Corp. RTL8151 Adapteon Business Mobile Networks BV After issuing the modeswitch command s...

ppp widget is not made for Android devices which has their own built-in support for mobile broadband usb dongles, it is intended for phones and tablets with an usb port but without built-in mobile broadband. The built-in support in your car head-unit collides with ppp widget. Use a dongle supported ...

So the rtl8152 adapter has an initial id of 0bda:8151 which changes to 0bda:8152 after switching, then we hit the second udev rule switching it from 0bda:8152 to 0bda:8153?
Sorry but that doesn't seem logical to me, I would guess that the rtl8153 adapter also has an initial id of 0bda:8151.

Ok, the print on the casing says it has wifi. Can you see it transmitting the SSID? Can you connect to it?

Your device, when it is in default mode, has the USB Id 05c6:f000 and that Id is supported for switching by usb_modeswitch then it gets the Id 05cf6:6000 after being switched. Trying to switch 05c6:6000 is futile and trying to switch a USB Id you do not have (05c6:1000) is equally futile. Your dmesg...

In one end you have udev detecting the device on the bus and taking the action specified in the rules file, in the other end you have the main usb_modeswitch program, I don't think they are responsible for your problems, manual switching works for you so the main usb_modeswitch program is ok. The gl...

Looks like the Generic usb_modeswitch rules for Huawei devices were messing with. So the rules file in Ubuntu 20.04 is not the same as the one used in your tests with 14.04 and 18.04? The general single line rule for all Huawei devices hasn't been changed since usb_modeswitch 2.2.2 and is still the...

Looks ok but: Enumeration is usually done by the kernel (udev or hotplug) not by the user, are you sure you need to do that by yourself? Be aware that some USB host controllers in otg mode must be forced into host mode or they may drop the USB VBus during the time your dongle is absent from the bus ...

When the device id is 161c:f101 then it is already switched (possibly by usb_modeswitch) and it can't be switched further. As you have noted there is a forum thread for this device under a different mfgr name but there was no final solution in it, the problem is unsolved. The net interface of the de...

There may be other problems remaining when you have got rid of the option driver from interface #0. I just realized that in your second usb-devices listing it only have one endpoint while in the first listing it has three (this is corrrect, the ncm driver needs three endpoints in order to bind). In ...

You can also download the Ubuntu usb-modeswitch package for "groovy" in which they finally have removed the driver loading from usb-modeswitch.

If you haven't done a manual bind of the option driver then there is only one possible reason left for why the option driver binds to the net interface and that is Ubuntu's modification of usb-modeswitch where they do driver loading for certain interfaces. This is something that was removed from gen...

The option driver is grabbing the net interface in the second plug-in, it does this only if you force it to load manually by using the new_id function.
Don't do that, when the option driver is loaded automagically then it knows to not take the net interface!