Transactions that spend unconfirmed change outputs from prior transactions which aren't entirely P2W* are exposed to being invalidated.
Because importation of old keys remains a supported feature, and people sometimes continue to pay to old addresses, and old style outputs can hang around in the wallet for an unbounded amount of time, the fact that immune addresses are now a default doesn't eliminate exposure. Running a wallet that has never had old keys, however does-- so this isn't the most cosmic of problems.
The software currently exposes "-spendzeroconfchange" which completely disables spending any unconfirmed inputs. This solves the problem but for most users it is has extremely poor usability, because the wallet will stop being able to spend when there is plenty of balance remaining simply because there isn't enough confirmed balance. For all except the largest users this is a common case. So spendzeroconfchange is mostly only useful during active attacks when not using it is clearly worse, or for the largest users.
Now that P2W* addresses have been the default for a while, the only exposure comes from spending change from unconfirmed transactions with old or mixed input types. I suspect a spendunsafezeroconfchange could be added, and perhaps could reasonably be defaulted to off. (Or it could be a wallet flag, like the address reuse one).
Because new change is created using P2W* scripts even the case of a one-input-only wallet being disrupted by spendunsafezeroconfchange=false should be close to a one-time event.
Even if it couldn't immediately be defaulted to off it would be a much less disruptive alternative to the current spendzeroconfchange.
It might be desirable to first adopt a "try to avoidpartial first" coin selection strategy, which would help sweep up vulnerable inputs or at least reduce the total number of mixed-input transactions which are created.
I don't know if spendzeroconfchange could be removed entirely at the same time, because it's also a privacy feature analogous to disabling reuse since spending an unconfirmed input pretty much identifies that input as change. (though ultimately, perhaps that should be done with a replacement into a sendmany ... which is also not particularly private, but at least its more fee/space efficient.)
Spendzeroconfchange=true also has an advantage in fee calculations right now independent of the invalidation concerns: At the moment, effective value and total-fee calculations don't consider the additional fees required when there is an unconfirmed input to bump the ancestor chain up to the requested feerate. So any spending of unconfirmed inputs risks underestimating the effective feerate for the transaction until the inputs confirm. (but still, spendzeroconfchange is hardly an adequate way of addressing that, since it just makes the wallet reject transactions since the unconfirmed spend was already a last-resort)
