The repository workspace is exclusively owned by the user. Another user has only read permission on it and CAN NOT deliver from it. You can accept changes from work items into your own repository and then deliver them.
Note, you might consider creating a repository workspace from user2's repo workspace. This will not necessarily do what you want to achieve. Unless the change sets are all completed (which only user 1 can do), you might miss some information.

I don't know what good reason one could have for this approach. I personally think this is likely to be a process behavior that indicates that the organization is broken and someone tries to fix the broken organization with a tool - which almost always fails.

There might be reasons to do something like this in very special cases, but from my perspective that would be the unusual case. One case where this is used is for backporting changes.

A better approach would be to have a stream, where the developers deliver against and the integrator accepts the incoming changes into his repository workspace and then delivers to his integration stream.