I don't think the SPV Miners have confirmed whether they have patched their software to do full validation so the alert remains and the situation persists.
I saw a quote by F2Pool - perhaps on this same thread - confirming that they will
not do full validation of the parent before mining on top of it. They will however re-enable validation of the parent in parallel, if and when they receive the full block from the relay nodes.
What the pools do (probably
all of them, because they will be at a clear disadvantage if they didn't) is more radical than "SPV mining". They subscribe incognito as members of other open pools. When some other member of some other pool X mines a block B(N), it will usually tell all its members to start mining B(N+1) on top of B(N), even before sending B(N) out to the relay nodes. To do that, it has to send to all its members the header template of block B(N+1), that includes the hash of block B(N). The pool Y that is spying on X will then take that hash and start mining its own block B'(N+1) on top of B(N).
This shortcut is usually quite safe, because pool X must validate the contents of block B(N), and cannot afford to send a false hash to its members, even though it knows that some of them must be spies for the competition. But this trick failed in the "fork of july" because pool X (BTCNuggets) was still running the v2 version of the software, so the block B(N) was invalid under v3 rules. The hash of B(N) was stolen from BTCNuggets by BTC-China, that was running v3 but did not realize that BTCNuggets was v2. Then F2Pool stole the hash of B(N) from BTC-China, and won the race to B(N+1); and the mistake continued for another 4 blocks more. A similar incident happened again on the 5th of July.
The pools obviously will not give up on this shortcut, unless some way is found to make it unprofitable.
Moreover, whenever pool Y starts mining on top of the stolen hash of a block B(N), it must start mining an empty block B(N+1). Pool Y cannot include any transaction from the queue in B(N+1), because it cannot check whether that transaction was already included in B(N), or tries to spend some UTXO that was spent by another transaction in B(N). Pool Y must wait until it gets the whole of B(N) from the relay nodes, before it can safely add more transactions to B(N+1). But often pool Y solves B(N+1) before that time. That may be the cause of the empty blocks that are often seen after a short interblock interval.