Personally, I consider the current behaviour as broken as I would consider print sqrt( -10 ); printing 3.16227766016838. Except that I can conceive of the situation whereby the latter result might actually be useful. I could see someone relying upon that broken behaviour and skipping the step of detecting negative values and absing them, if that was the requirement of their application. They shouldn't, but I could see it happening.

However, the current resultant of substr as an lvalue, whilst predictable, is so twisted, and has so many edge cases, I find it inconceivable that anyone has actually found a reasonable use for the current behaviour, much less constructed an application that relies upon it.

I have personally encountered the situation (twice at least) where having the value assigned, returned would have slightly simplified my code.

As such, I would consider this change fixing a broken behaviour, rather than modifying an existing, useful one, and if it served to highlight broken code, or reliance upon undocumented, broken behaviour in existing applications, then so be it. Simplistically, if adding 1 + 1 returned 3 and someone coded their app to rely upon that, we wouldn't think twice about not maintaining backwards compatibility.

To my way of thinking, this fits in the same category.