Doesn't fully help? Could actually be more difficult if you let the driver do the TCP ack. And you are likely going to back yourself into a situation where you need TCP between the application and the driver... Remember, at that point, it is just a message pass, as well.

There is a good article somewhere about how you have to do end to end for any of this to really work.

If your network stack is running isolated to your wifi driver (with the interface being frames to send and receive), it's fine: the network stack just sees some dropped packets the same as if something else dropped them. If your network stack with your TCP state crashes, then it's a bit trickier: the connection will likely be dropped, which requires an application-level retry, which also will generally already exist to deal with more significant network issues. I don't think you've picked a great example for this kind of problem.

I would assume that the TCP state would be part of the "networking service" that is isolated from my application. As such, I'm assuming the more complicated situation there.

That said, I don't make too big of a defense of networking being a bad choice. At large, that is literally where you have to do distributed computing anyway; so, agreed a lot of it will be covered for a lot of applications. I was trying to stick to the examples others chose as I'm not really trying to "gotcha" to anyone. My main point was honestly more about how similar that is to how we are today. If you were in a microkernel, is it any easier? Because that is the original goal post here.

I do further question why you'd want to do that for every subsystem interaction, and if you really want to have to redo all kernel context swaps and local message passes if something went wrong locally.