Speaking Of Things Nobody Tested...
Confirmed this with a few people now.
If you have a sequence, and you update it, and then say, you delete the _2.sft after making a _3.sft (because why have them all lying around wasting space) and you open the sequence, make another changer, then save it. You will get a _2.sft 90% of the time.
Which when put into the console will say it's not the right version lineage.
Thereby giving you the choice of keeping all your SFT's around, forever, or jumping through a bunch of hoops trying to get it back into a correct lineage (like, say, dumping the entire app out of the console and reimporting it, which will again 90% of the time give you all kinds of problems because the clients will see they aren't supposed to have it, but do have it, but it's the wrong version, so the only way to fix it is to manually runn SFTMIME commands on each machine to clear it out).
Let's call it what it is.
Really poor software. In no way, shape, or form acceptable for a paid product from one of the largest software companies on the planet.
Along with this and the bug that is STILL in 4.6 SP1 where it reverts to "generate MSI" being checked everytime I can only say I hope they abandoned (there is no other word for it) 4.6 in the hopes of making 5.0 something that is actually ethical to charge people for.
That being said, IF you have version 1 of your package you may have reasonable success with attempting the following:
Add Version 1 to the App-V server, then add the newly created _2.sft package, then remove the version 3, or 4 or whatever version you are up to.
Past that though, you can't delete Version 1 or you will have the problem again, you can't delete it in your backup repo because, again, you will have the problem.
You will need one copy of ever _sft generated or risk running into a problem where you can no longer update the chain.
One more quick follow up.
I found a fairly consistent way of getting them back on track seems to be opening them in AVE (which can be found over at Gridmetric) saving them, and then opening them in the sequencer, if I had more time (or when I get more time) I would go through the XML and SPRJ and figure out which field isn't set correctly and manually "fix" it. For now, if you have AVE, it seems to work for the couple of us who have tried.