This is real creepy ... TI should bug-test their software more (yes, we can dream)
Anyway, I think this is news worthy!

So do I. What do the modos/admins say? Do we have enough proof?
I'm preparing the TI-Bank news.

If TI bricks are calcs with their software can we get replacements for free or would we need to fix it on our own?

If it's still under warranty, they'll repair/replace it for free. If not, I doubt they'll admit it's their fault.

That's why I've asked if someone who "understands" the decrypted OS was seeing any trace/proof of this major bug in the 3.0 OS boot2 update code.

Wow this is terrible. I'M glad I ran my OS through TNOC before upgrading.

I suspect the problem is a race condition between the boot2 updater and the filesystem. There could potentially be filesystem access going on concurrently with a boot2 update and as far as I know there is no synchronization to prevent one from screwing up the other.

Edit: haven't been able to confirm this. The only two tasks accessing flash are the main task and a FlashFX background task. The boot2 updater is run from the main task, which has a higher priority than the FlashFX task. So even when inserting large delays into the boot2 updater, the FlashFX task doesn't do anything until long after the update is finished.

They try and stop the hacks the community have created up to os2.1 by enforcing more anti-downgrade protection in their NEW os but what they do is instead recreate a situation like os 2.0.0, where ti-nspire's were bricked. They better release the update soon, because the longer they leave it, the more chaos there will be.
So major upgrade (just to catch up with Casio, and force anti-downgrade) = Dead Ti-nspires