My long-term plan for CMSIS could be best described as "wait and see". If people need CMSIS for stuff, I may add support. In at least some sense, I've already done this for CMSIS-DSP. The arm-math.h header is in the core library, so you can #include it, and the library is linked, so you can indeed use all the CMSIS stuff. The FFT and FIR filter in the audio library does.
The idea is that CMSIS would allow more code cross-pollination. I believe that would be ARMs compelling argument for using it.
But I'm certainly not going to redo all the low-level I/O stuff which already works very well, and far more efficiently than Arduino Due's CMSIS-based approach, simply for the sake of using CMSIS. I really couldn't possibly care less whether ARM calls it a standard and whether Arduino is using it underneath their core library functions.
That's the cool part. You don't have to redo them. You use both and/or replace with yours.
All it really requires is some code reorganizations as to where you place them in the tree, and possibly a little bit of code refactoring for anything that would conflict in namespaces. Looking at the Teensy arm core briefly, I don't see any collisions.
I will only add CMSIS support as it's actually needed for real projects people need to do, and as it provides real benefits for people doing real projects with Teensy.
I'd argue here that it may be an advantage to use a mix-- Your excellent code interfaced as an CMSIS 'board'.
This would allow you to keep all that you want, and have worked so hard to develop and tweak, and to use what is provided in Arduino >= 1.5.
Looking at the 1.6 layout, and provided tools, you could eliminate your own arm compiler, newlib, and use the Arduino provided ones.
Any ARM Teensy specific/optimized drivers would go into the ARM teensy library variant directories.
The one bit that I actually totally love about the CMSIS part is that driver components, if not required, won't get included into your binary.
This is an actual gain when you think about it.
For example, if you are not using USB, then you eliminate all the code for it; the current code doesn't do that.
Not only will you save on flash space, but that section of the chip does not get powered up, which saves on battery.
I'll actually be needing to do this in a project that I plan on having completed shortly, which is ran on a Lion battery and recharged by solar.
It will be recording and logging environmental data to SD card, and has to be as low power as possible in order to be able to recharge the battery, and to survive continuous operating at night.
The more sections I can power down on the chip, the better the chances I have at making this cost less -- Smaller battery, smaller solar cells.