Actually segwit has cases like this.  As I wrote in my last post, if you take a segwit transaction and strip the witness data off it, then it will be a valid transaction under the old rules but not valid in the new ones (because it is missing the witness).  Adding restrictions like this (in the case of segwit, that the witness is verified in addition to the old-style signature) actually is the only point of a soft fork, and hence why you may call it "enforcing segwit".  gmaxwell's mention of "safe" is very useful in the context of this discussion, but if you re-read his answer precisely, it only states that that means "extra care" is taken.  My quote above, as it stands, is correct as far as I can tell.

Perhaps it is easier to illustrate this with the BIP16 soft fork instead of segwit.  In this case, the validation rules for scripts were modified, so that

OP_HASH160 [20-byte-hash-value] OP_EQUAL

would be validated according to the old rules (i.e. you need to provide a preimage for the published hash), but also the preimage itself must validate as script.  Pre-fork, you could spend a P2SH output by simply knowing the redeem script itself, even if you did not provide valid signatures for it - because that is what the script above says.  The soft fork then introduced the bolded extra rule, so that P2SH would work meaningfully.  But this means that you can produce blocks and transactions that are valid for pre-BIP16 nodes but invalid with BIP16.  There is one pre-BIP16 block, 00000000000002dc756eebf4f49723ed8d30cc28a5f108eb94b1ba88ac4f9c22, which actually has this situation - it is valid pre-BIP16 (and is valid because it was created before the soft fork), but it would not be valid anymore now due to the added restriction.

But maybe we are just misunderstanding each other's meanings.  I think the OP's question related to the use of "old mining pool software" has been answered.