I think you guys are missing my points. And by the way when I say "developer" I mean anybody writing Arduino code not necessarily what someone might call a true/real programmer.
The main point I'm saying is don't pollute the API name space with an entire set of new API functions. Simply layer the API in 3 functionoal layers (which is what my original suggestion was) and tack on under bars "_" to get the names for the additional layers rather than dream up cutsie new names for functions.
Functionality of a given API call is independent of its timing. Often additional functionality impacts timing but this is not always the case.
Those that want to delve into higher performance alternatives to the existing functions which do not offer all the handholding should have a way to do that. Those that want want the additional hand holding functionality of the currently defined API can still have it. And those what want to ride any performance increases due to new and better library code being written without them having to modify any of their code should also be able to that as well.
Again, functionality of a library API call is independent of timing. (well except for time delay API functions) In some cases it is possible to preserve all the functionality yet make it much faster but in some cases it is not.
Consider the very recent Arduino library fix for atomic bit access. This is now in the mainline code and will be in the next release. This will slow down all digital pin operations. What about that type of change? Is it also unacceptable to slow down an API call?
API functions should only offer to maintain the functionality defined, and if timing is not part of the API specification, then timing should not be a limiting factor in the implementation.
I also think that since it is possible to offer a higher performance interface with the very same API inteface and functionality by simply re-writing the underlying digital pin code, that the API library code should be allowed to be updated to take advantage of this rather than being bloated up with new API functions that are exactly same only with different timing.
And that users of Arduino need to understand that they cannot depend on certain timing behaviours being maintained across all releases. Those that need such exact timing behaviours of what they have in a particular release can simply stay with that given release and not upgrade.
This is no different than what currently happens in the commercial world on real products. Once you have a working product in the field you sometimes have to lock down toolsets. It is simply not always possible to upgrade to the latest greatest tools release even if you want to.
I suspect many developers wouldn't use the fast version.
For example I wouldn't use it in my library for playing audio on the Adafruit Wave Shield. The hardware SPI is used to read from an SD card so it uses bit-bang SPI in a timer ISR to drive the DAC. It must send 88.4 KB/sec to the DAC for 44.2 ksps Wave files. I just want total control over optimizing this small but critical part of the library so I would not use a new fast digitalWrite.
Now this depends on how it is presented. If it were faster by default (preserving the same behaviour), then most people would use the "faster" i/o (maybe not the fastest as that might take using an _ (underbar) function with less functionality) and those that couldn't handle "faster" would go in and update their code (which might be as simple as a define or include) to revert back to the existing bloated code and slower behaviour - assuming there way to re-enable that code.
The point being nobody really knows what percentage of users actually need or depend on the current slow Arduino digitial pin code implementation. My belief is that this is a very small minority and the vast majority of the users would actually see little or no difference and a small fraction would be happy with the increased speed.
It seems so odd to be defending a poor code implementation that is slow and bloated. Normally people are happy when new versions of code could get faster or smaller.