PaulS:
Hopefully this will help everyone, and I would appreciate comments.
Probably not mine...
I think that it is important that people UNDERSTAND the blink without delay example. Providing some macros that hide the details is not going to help.
The concept is pretty simple, but the ease of use of delay() suckers many people in. Making blink without delay's concepts easier to use is not necessarily a good thing, if that detracts from the ability to understand the concepts.
And, it is my humble opinion that macros do just that.
I should have addressed this point in the first post.
Using delay() means that it becomes impossible to use any other scheduling method, like the one presented here or whatever else. Using this macro means that you can use a different scheduling method for something else. So if people get "suckered in" to using this macro, then instead of telling a new user "Sorry, it's impossible for you to add a second LED to your code without rewriting the entire thing," the user can just learn how to do it the proper way then and go ahead.
I agree that this macro may impede learning, but not necessarily in a way that will affect users. Once users "outgrow" the macro, they will learn how to do it the manual way just the same as they would if they initially were using delay.
I feel that a macro such as this one is consistent with these, ie consistent with the arduino philosophy.
#define lowByte(w) ((uint8_t) ((w) & 0xff))
#define highByte(w) ((uint8_t) ((w) >> 8))