Can't you circumnavigate the "naive" way simply by having those "automatically generated" receives as unconfirmed (not cemented) and change their order based on something universal among all nodes (like alphabetically based on link) and then only confirm then as the chain owner adds a new block with his signature? Therefore confirming all automatically generated between his last signature and this one?
I don't know the details of your discussions over there, but I imagine something like this:
The node process and confirms a send. It locally generate a receive on the receiver chain without signature. A new send is made. A new receive is generated, but since receives can be done in any order, you order all the non signature receives by link. Then the chain owner sends a signed block (send or change). That confirms all the blocks between his last signed block and the new one.
For example, an account has frontier N (signed block). Now someone else starts sending them Nano. The node locally starts creating receives and adding them. To every new receive it re creates all "pending" receives according to the link order. So for the first send with link 500 it creates a receive with height N+1. Now the second link is 858. Because 858 > 500, it creates a new receive with height N+2. The third send has link 150. The node locally re orders the receives. Now link 150 is N+1, link 500 is N+2 and link 858 is N+3 and so on. For every new send to that account the node has to recreate the chain of receives. This should not be very resources demanding since it's only about ordering a list and rehashing every block. Anyway, this goes on until the chain owner send a signed block. He will send a block with height N+X, x being in theory the amount of receives that is pending, but could be anything. If it does not generate a fork, fine you just confirmed all the receives you had pending. If it does, you confirm it anyway as a fork (the receives are not cemented, they are only cemented by a posterior signed block, and the network never votes for a non cemented, non signed block over a signed one). The receives that were orphaned (between frontier and N+X) are recreated and added on top of the signed block.
The ordering process guarantees that all nodes have the same order of receives, even if they were all created locally and have never been on the network. If somehow you see a send that you don't understand the previous, it means you either generated wrong receives or you missed a send and therefore didn't create the appropriate receive locally, and the fact that the receives are not confirmed prevents the issue you described, he could send with the "wrong" previous, that would only affect which of the receives were confirmed and which will continue to be "unconfirmed".
EDIT: More considerations:
Instead of re organizing the chain at the arrival of every new send, we could do it only once when a block is to be cemented. Having the unconfirmed receives in a different orders in different nodes would not be an issue since they would all add to the same info (balance and rep). Once a block needs to be cemented you re org to make sure all chain on all nodes are equal.
Downside of this option is that you can't prune send blocks whose receive is still unconfirmed, just like now. This could be solved triggering confirmation process for locally generated receives under some specific condition, like amount of pending receives. Then nodes would order the receive list, and request confirmation for the one that hit the the criteria for confirmation, while other nodes would validate if the same conditions apply.
I don't think this would cause the same issue as described by Colin above because the account owner would still not have to use the "correct" (latest) receive, just one posterior to the one that was cemented. So a condition like "if unconfirmed receives list > 100 blocks, confirm first 50 unconfirmed", would still leave room for the account owner to send with any height from 51-100