A tun/tap interface always belongs to some application: Packets send to the interface get read by the application, and packets written by the application enter the kernel network stack through this interface.
Typically, you'll connect up network namespace with virtual ethernet pairs (veth). They just forward packets to the other interface of the pair.
Nothing stops you from writing an application that does exactly this: Open two tun/tap interfaces, read packets from one and forward it to the other, and vice versa. There are also ready-made applications you could use to do this, e.g.
You can even write two applications, where each application opens a single tun/tap interface, and the applications communicate with each other using other means, and implement forwarding this way. Basically all VPN applications work this way (though for VPN applications "by other means" is typically "over an existing network connection", so it doesn't really count).
So yes, with the right application(s), you can connect namespaces with tun/tap interfaces. However, in general it doesn't make a lot of sense to do that, because you have to write such an application, and it will be less efficient than just using a veth-pair.
I tried moving one tun interface of
socat into a network namespace
ns0 I created, and it works fine as I had expected, despite
socat running in the main network namespace:
socat TUN:10.1.0.254/24,tun-name=tun0a,iff-up TUN:10.1.0.1/24,tun-name=tun0b
ip link set tun0b netns ns0
and then you again have to set the address for
tun0b after the move.
So the "crossover" happens by having one (or both) tun/tap network interface(s) in a different namespace than the process.