I believe you're complaining about something that changed between Basic 1.2 and 1.3 (back in the early 80's). In fact, I remember writing a letter to Alpha Micro to complain about it, which may have been instrumental in me getting involved in the dealer/developer/advisory committees, which in turn probably led to ... where we are today. (Perhaps I should give you a chance to take the question back?)
It's probably not fair to expect Stephen to help you on this one, as he wasn't born yet when the change occurred.
Here's the explanation of "what" (I never did get a decent answer to "why"):
When a string subscript expression involving a negative starting or ending position (i.e. one that is measured from the end of the string rather than the beginning) occurs on the right side of an assignment (i.e. it's a source expression, sometimes referred to as an rvalue at least in C programming lingo), then the index position is calculated relative to the logical length of the string, which is what you would expect.
However, when such an expression occurs on the left side of an assignment (i.e. it's a destination or lvalue), then the index position is calculated relative to the physical length of the string (i.e. the mapped length).
So your first two assignments put "A" in the last physical position of the string x$. (And assuming that x$ is truly a string and not an X variable, as a side effect it replaces any nulls between the "A" and the previous end of the string with spaces.)
I agree that it's confusing (and it certainly wasn't any easier to implement this way), but as you can imagine, this kind of detail is critical if we are going to preserve compatibility with old applications. (And if it makes you feel any better, I recall spending many hours back when the change happened, first trying to figure out why my programs weren't working as they used to, and then trying to find and repair all the places the relied on the original behavior.) The documentation was never explicit about it, so I guess they decided the change was a bug fix rather than a change of behavior.
Your last statement works as you expected because len(x$) returns the logical length of the string (again, assuming that x$ really is a string and not an X variable. From looking at others' code, it seems that some people like to use the $ with unformatted variables, which really confuses me.
Note that because of the murky nature of the "physical" length of a dynamic string, expressions like your first two should be avoid with any string that might conceivably be converted to dynamic at some point in the future.
