There are several possibilities of dealing with UDP traffic in OMR.
1) Multipath VPN (glorytun).
Thing is that UDP spread over multiple paths will not as well as MPTCP. MPTCP creates multiple subflows, one for each available path. Each subflow behaves (roughly) as a separate TCP connection, carrying some part of the traffic that goes through the pipe (byte-level splitting of the traffic, not packet-level). What's important here is that each subflow has its own separate congestion control.
The congestion control mechanism [1] is a very important aspect of TCP that basically controls its speed in a way that your internet connection is not overloaded and concurrent connections aren't disrupted. QUIC also includes a congestion control mechanism. But with MPTCP, each path is treated individually; with QUIC-over-multipath-VPN, where we just spread UDP packets somehow over multiple paths, the congestion control mechanism will get confused, b/c in the reality the congestion can happen separately on each path which will be hard to see; also, there will be packet reordering which will not improve the situation either. Basically, this is what happens when you try to spread plain TCP over multiple paths naively, and it's the reason why MPTCP was invented in the first place.
2) UDP-over-TCP.
In this case, I'm afraid that given that QUIC has its own congestion control, we might get unpleasant side effects similar to "TCP meltdown" as in case of TCP-over-TCP [2]
1) Multipath VPN (glorytun). Thing is that UDP spread over multiple paths will not as well as MPTCP. MPTCP creates multiple subflows, one for each available path. Each subflow behaves (roughly) as a separate TCP connection, carrying some part of the traffic that goes through the pipe (byte-level splitting of the traffic, not packet-level). What's important here is that each subflow has its own separate congestion control. The congestion control mechanism [1] is a very important aspect of TCP that basically controls its speed in a way that your internet connection is not overloaded and concurrent connections aren't disrupted. QUIC also includes a congestion control mechanism. But with MPTCP, each path is treated individually; with QUIC-over-multipath-VPN, where we just spread UDP packets somehow over multiple paths, the congestion control mechanism will get confused, b/c in the reality the congestion can happen separately on each path which will be hard to see; also, there will be packet reordering which will not improve the situation either. Basically, this is what happens when you try to spread plain TCP over multiple paths naively, and it's the reason why MPTCP was invented in the first place.
2) UDP-over-TCP. In this case, I'm afraid that given that QUIC has its own congestion control, we might get unpleasant side effects similar to "TCP meltdown" as in case of TCP-over-TCP [2]
[1] https://en.wikipedia.org/wiki/TCP_congestion_control
[2] http://sites.inka.de/bigred/devel/tcp-tcp.html