Writing something in a high level language is great an all for displaying a concept but you have no idea how much processing time it actually takes until you put it in assembly. I’ve written the equivilent of what you’ve described here. The current serout command can handle a max of 57600pbs. Add in the necessary code to process what you describe above and the serout command will max out at half that or even a quarter that rate. Same applies to all the other timing critical functions. Pulsout would have half to a quarter the resolution and 2 to 4 times the minimum pulse width. Pulsin would probably be worse, approx 4 to 6 times the minimum pulse width because I already had to do some very nasty coding to get it where it is. In other words, it was a no brainer. I went for top performance of normal commands instead of tweaking everythying out so that interrupts had no effect on those commands. The simple fact is interrupts are not something used by 99.9% of programmers using basicstamp style micros. There is a simple solution to remove interrupts from messing with your timing critical code. Simple disable the interrupt while processing that code.
Sorry I appear to have pressed a hot button. 
It was simply a possible solution to fixing a timing issue timing issue I ran into using your interrupt code for the BRAT and trying to run an LCD using your serout command at 9600 baud. If this is something that you are not interested in or you do not think will work for you, that is fine.
FYI - the last time I used something like the WaitClockTicks function was on an AVR Atmega32. Depending on compiler flags, I believe the inner loop was 6 or 7 clock ticks per loop and in timer critical area I had this in C++ as an inline function so the subroutine overhead was 0. (Yes many C or C++ programmers do really look at the generated code)
Not a hot button, just trying to explain why it doesn’t work. In your own example you say the loop take s6 to 7 cycles. My current timing routine takes a min of 45 cycles to process but is accurate to 1 clock cycle and uses no hardware devices(eg timers). If you can live with the 6 to 7 cycle loop period(eg resolution) then yes you can do what you described. Of course I could reduce my initial overhead from 45 cycles to less than 20 cycles if I didn’t need a 1 cycle accurate timer.