writing complicated but future proof code

I'm working on a project and we are trying to keep things as simple as possible on the hardware and software end, this means install arduino and cut and paste the code in and hit upload, no libraries or figuring out where they go or figuring out configuration file settings or any other options that would otherwise frustrate a non-geek so that we have the widest target audience possible for this DIY.

But the application is not terribly trivial (monitoring fuel injectors and speed sensors and interacting with the user and providing several forms of data display and trips, etc, to improve fuel economy). So there are a lot of overlapping and precise events to be timing.

So initially "peeked under the hood" at millis() and noticed that you can get a more precise timestamp than millis, and put a function together that also gave the elapsed microseconds based on that timestamp. Problem is I cannot (and should not) rely on millis implementation details.

But I cannot also ignore millis and do my own timer0 ISR (makes duplicate definition compiler error). So I would like to use a timer1 ISR for more precise timing and to set up an event scheduler (re-enable the speed sensor interrupt after debounce period, re enable button1, 2, or 3 interrupt after debounce period, trigger a trip update, trigger a display refresh, etc.).

So is timer1 code "future proof"? Is there some guidelines as to what is "safe" to leverage for future arduino versions? Certainly the internal workings of a function are not safe, but can I make any assumptions about, say, timer1? or timer2? If ISRs become core for those then I will be broken if I follow this path.

The Timer 1 ISR will probably not be used in the core any time soon (as we're planning to have it available for things like a hardware servo library, etc.), but no guarantees. The best would be if you can release updates to your users for new versions of the Arduino software.

Alternatively, if you have a good implementation of a micros() functions, that might be something worth incorporating into the core and keep in sync with the millis() implementation that it relies on.