This whole feature doesn't even sound possible. I can't find any details about how this feature is supposed to work, but there has to be more to it than "it magically opens another connection and it just works." The Wifi and Cellular connections have different IPs. The packets would suddenly be coming from a different IP address. TCP and UDP do not support that.
At the transport layer, suppose a phone is on Wifi at IP 126.96.36.199, is authenticated, and is receiving data. Suppose the cell connection is 188.8.131.52. There's no way to tell the server "Hey, I know I'm on 184.108.40.206, but I'm actually that guy who was on 220.127.116.11 a moment ago, so start routing my packets here." You can't pick-up a TCP stream and just continue it on another IP address. UDP won't work either, because it will ignore packets from 18.104.22.168 and keep sending to 22.214.171.124. That is why cellular voice connections use special protocols where the towers negotiate with each other. There is unique design considerations for such a hand-off and most protocols don't consider that.
Supposing the transport layer could solve this, the session layer won't allow it. When you log in to a network service, you send credentials and get back some kind of security token. Those tokens are usually not valid when sent from another IP address. That's a pretty common security best practice.
You would need the application to realize that the connection went bad, then renegotiate the connection on the other IP address by sending the login credentials and accepting a new security token. Then it would need to tell the server to continue the connection from the point it left off. The OS can't do that for you.
It seems to me that if the OS transparently sent the packets from another IP, even if the server somehow got those packets, and for some reason the TCP stack routed it to the application - which it would not - any well written service would probably assume it was a hack and log both connections out. Or at least ignore the second one.
I also wonder what the OS would do if both connections returned data? Now there's 2 response streams for 1 single outgoing stream.
The only way that I could see this working is if some other server in the middle is proxying all your data, and there is a way to tell the proxy about your new IP address.
Here's a SO post on the topic of changing IP addresses:
Here's an academic paper on a proposed modification to TCP to allow this: