In general, the compiler doesn't know, when compiling f(&x), whether f modifies x, because f might be defined in some other module. So at least in those cases it must assume f modifies x. For consistency, it always behaves like f modifies x.
I can see why the quoted documentation from TSPL might be confusing: it reads as though step 2 ("the copy is modified") is obligatory or somehow meaningful to the semantics of inout before step 3 occurs ("the copy's value is assigned to the original argument").
This is not true (cc @Alex_Martini)—it would perhaps be more accurate to say that the copy is modifiable within the body of the function, but there is no step 2 required as it is currently stated in TSPL.
Whether the copy is modified in the body of the function is immaterial to the semantics of inout, and whether the compiler "knows" what's in the body of the function is also immaterial. The function can be an always-inlinable function with an empty body that has guaranteed semantics that it does absolutely nothing. Nevertheless, the semantics of inout are such that a copy is notionally assigned back to the original argument when the function returns. Notionally because no actual copying needs to happen at all. However, with respect to all observable behaviors (including didSet), it is as-if such a copy occurred.
Let me modify this statement to clarify the semantics of inout even stronger: the copy of the inout argument actually doesn’t need to be modifiable at all.
You can explicitly choose the internal argument name of _ in the method signature of inoutBar, guaranteeing at the point of declaration that the copy of the argument’s value cannot be accessed in any way from within the function body regardless of what code is in it, and the didSet will still be triggered:
That's kind of funny, I never thought about using _ within a function's parameter declaration (but of course it makes absolutely sense that it's possible, grammar-wise).
If we're talking about this and considering beginners might read this here, however, I feel the need to add that "this probably is a bad idea™". The example with didSet here basically shows how to use a side-effect to do something and that often indicates a less-than-optimal design of your code in a more general sense.
After all, if you don't need a parameter inside your function you should consider why you won't leave it out entirely. (That being said, one argument surely might be "I am adopting a protocol and the definition demands this", which is encountered in a ton of delegate patterns).
Same for the inout part of it. There sure are scenarios in which that can happen and unexpectedly getting didSet invoked is not easy to avoid, but if you're in full control of how you define your functions and/or properties it's probably unwise to do something like this intentionally. You're more likely just "hiding" something from a future reader (who might very well be yourself).
Just to add a little bit of context here, I intentionally created a simplified version as an example. But in our real project it was a @Published property that was triggered for ref types which I didn't understand. After some digging I found out that it was used to call a func with an inout param. So I've decided to ask here