Async vs. borrows

I'd like your thoughts on an issue I ran into while designing wasi-sockets:

Some operations require exclusive access to a resource while the operation is in progress.
The component-model already prohibits multithreaded access by default, so there is no problem so long as the function completes synchronously.

However, if the function needs to perform IO during its operation, the component-model's protections are not enough. Because, while parallel access is disallowed, concurrency in general isn't.

In the wasi-sockets proposal specifically, I run into this issue with mutating & async methods like connect. Simplified example:

set-ttl: func(this: borrow<tcp-socket>, ttl: u32) -> my-result
connect: func(this: borrow<tcp-socket>) -> future<my-result>

Here, connect is async and both set-ttl and connect change the socket state. Calling set-ttl while connect is in progress should not be possible.

At the moment, I've introduced a distinct error code for this scenario and plastered that all over the API's. As can be seen here: https://github.com/badeend/wasi-sockets/blob/error-codes/wit/tcp.wit (search for concurrency-conflict)
Now, this can work fine as it is. I was just wondering if the component-model could be of any help here.

IIUC, the component model can already solve this issue (ableit very hacky) by changing the connect signature to swallow a unique reference and spit it back out at the end of the async operation:

connect: func(this: owned<tcp-socket>) -> future<tuple<owned<tcp-socket>, my-result>>

It's just not very ergonomic. And the "same" resource would probably get a new index after the future resolves.

Start with the issue's wasi-sockets example and inspect wit/tcp.wit, especially the uses of concurrency-conflict. Compare the borrow-based signatures with the proposed owned-resource and future signature. Done would require a clear component-model design direction for preventing concurrent mutation, but the issue does not define a concrete implementation task.