The strict_types directive is limited to applying strict type checking, throwing a TypeError instead of doing implicit type casting.
The strict operators RFC is trying to do the same. Unfortunately there are a view of cases where this isn't easily possible and the statement will have a different result based on the flag. After a fierce discussion, the general consensus is that this should be minimized as much as possible (if at all).
With bc-breaking changes, there has always had a similar notion. The old code should have the same effect or throw an error. Exceptions to this exist, but are rare.
The P++ and edition proposals go completely against this premise.
Secondly, introducing such a dialect would ultimately break up the language and stagnate the progression of PHP in general. For instance, I'd fear that something like the deprecation of the left-associative ternary operator would not make it into PHP 8, but instead would be forced towards the P++ dialect. Even though this has nothing to do with loose vs strict types.
We should look and discuss to find alternatives that allow PHP to progress, but where bc-breaking changes result in an error (as much as possible) and do not (radically) change the behavior of PHP.
Arnold Daniels - Chat @ Spike [4202n]