As code modules, those two things are separated. The usecase doesn't need to know about the gui and vice versa.
In theory, they can even be reusable.
We combine those two things in the glue code. Thanks to the glue code, it's the usecase which drives the other things. The usecase makes sense even without thinking about a specific GUI solution.
I'm not sure where we could put the second piece of code you mention. Any suggestion?
The difference is that you do it by modifying the model and view, and that is the problem to me: You are making non-local modifications to the code, which means that while you are separating it in source, you are not keeping a separation in the running code. You make it extremely hard to reason about the system.
This is already a problem in large event/notification driven systems, but this takes it to the extreme by removing the hint to look for non-local behaviour by having the equivalent to the notification imposed by an external actor.
If you want to improve on a notification driven system, in my opinion you don't do that by making the extension points less obvious.
And if you first are going to do that, at the very least do it in very obviously named functions, and don't modify passed in objects by make copies. But to me, those are workarounds to ameliorate a situation that's already undesirable. E.g. if you're making copies and modifying the copies and keeping those internal to the glue class you might as well go back to implementing an actual controller.