I refer you to an earlier quote in that same proposal (emphasis added):
But name is immutable and therefore is not actor-isolated.
[Edit: While the code snippet in the proposal clearly states that name is not actor-isolated, that assertion is arguably too strong (or perhaps even technically incorrect?); the issue is more subtle than that: If you access this immutable Sendable property from within the current module, it behaves like a nonisolated property, one that you can access synchronously. But if you access it from a different module, you can see that it clearly is isolated, available only offering asynchronous cross-actor access (i.e., one must await it). All of this is discussed in the Cross-actor references and Sendable types section of the proposal, as well as in the Alternatives Considered: Cross-actor lets.]
Yes, counter is actor-isolated because it is a mutable property of the actor. That’s why g(), which is also actor-isolated, is free to access properties of its own instance.
Because g() is actor-isolated, it is free to access its own self.counter (as in 3), but not to other’s (as in 4). An actor-isolated method can access its own instance’s properties, but not to reach in an access another instance’s property (or at least not without an await).
In short, the isolation of self (e.g., within g()) should not be conflated with the separate isolation of other.
The point is to note that, unlike 4, where it (incorrectly) attempted to reach into other and directly access one of its actor-isolated properties, in 5 you are obviously free to call actor-isolated methods of other (such as other.f()). But the key is that g must await the call to other.f(), even though f() is not an async method, because other has a separate isolation context than self.g().