I personally don't like the "developer version" idea. In my (as someone who has written several calculator programs, including a clone of the chrome dino game and a port of a networking stack) opinion, the main two draws of calculator programming are the fact that you already own a calculator, and that the limited hardware available to work with, which requires you to write optimized code. A "developer edition" calc fails to meet either of these conditions, as someone who picked up a calculator for math class isn't going to choose the developer edition. At that point, you might as well just use a fantasy console or develop for another platform. Secondly, a more powerful developer edition would remove much of the challenge from calculator programming, and you might as well be writing an Android app. Finally, the total market for such a calculator would likely only be a few dozen to a few hundred people, so it would be unprofitable for TI to develop and market.
Finally, about the developer OS, that looks good on paper but would likely have a bunch of issues if actually implemented. Many teachers don't use exam mode and instead reset students' calculators (which isn't a good idea, as you can archive programs to preserve them across resets, but whatever). Additionally, a student could inadvertently install the developer OS (while blinding following a tutorial to install Mario, perhaps) and not be able to use their calculator on an exam because they didn't know they needed to uninstall the dev OS. Lastly, a student using the developer OS could just use assembly to fake the test mode.
It's clear that TI don't actually care about security, only the appearance of security. The incident that caused this resulted from outdated OS versions, and releasing a new OS version isn't going to do anything to help fix that. If TI really wants to ensure that their calculators are secure, they should tell testing institutions to require that students' calculators are updated to the latest version, stop giving developers a reason to release exploits by keeping native code support, and start working together with the dev community through a bug bounty program or similar. It seems very unlikely at this point that they will implement any of those, though.