Thank you @Bastien Montagne (mont29) . I did discover a workaround which was to wrap the script in a function that is appended to the app handlers. Consider the following script:

Suggestion: Manipulators on Camera and Lamp objects should be accessed by entering Edit Mode for these objects.
For instance, one could select a Spot Lamp and press Tab to enter Edit Mode, which would expose the manipulators for size, angle, and falloff. These would be hidden in object mode so as to avoid clutter. Entering edit mode on a Camera could expose manipulators for viewing angle, shift, focus distance and clipping.

This will probably get archived as not-a-bug, but I agree, and I think this functionality should be reconsidered for 2.8.

That was 8 hours turnaround time. Excellent work, Sergey!

Thank you, aligorith!

The video output and encoding panels are poorly organized and misleading.
Here's the full proposal on how to fix them.

Interesting. Would this difference necessitate the smoothing of all normals in BGE deform?

Good lord, this issue has been up for 2+ years? It seems pretty critical. Who can be bribed to address this? I swear I'll bake them a cake.

Oops! nearly forgot the file:

I vote that the walkthrough feature go ahead and use scene gravity by default. It'd be silly to keep it hard coded, and confusing to make it distinct from existing scene settings.

Teachers and tutorial writers are the main- if not sole- user group that need an addon like this. The purpose of screencasting clicks and key strokes is so that a viewer who is new to Blender can know- at all times- exactly what buttons the instructor is pressing. So, if a limitation of the screencast keys addon presents an issue for tutorial writers, then that is a drawback to the addon as a whole.

Perhaps the input could be de-limited only in actions for which it is appropriate. But for what it's worth, I'd rather be able to break something than have to deal with artificial restraints. That's more like the spirit of Blender, right?

Invalid. Viewport color is not supposed to affect the material's actual rendered color.

Here are the settings you're looking for. You left these untouched!

I don't believe this is valid.

I'd like to add that this seems like a widespread issue in Blender. Often when an object's property is driven by another property of itself, there seems to be a lag of one logic tick, even though the dependency is not cyclic. This bug can be reproduced simply by driving the rotation of an object by its location. The "extra object/data update" hacks do not appear to remedy this.

Interesting! I'd say that this is technically not a bug...

Certain modifiers do work in a stack; the envelope modifier for instance will deform a sine wave function, but a sine wave function can also come after the envelope.

Sounds like Auto Perspective has been enabled by default in 2.70. Not a Bug. Feature!

BTW, my company is producing an online Blender animation class for children. I understand the devs' reluctance to fix minor bugs so close to an official release, but we're launching quite soon so I'm worried that if this bug survives into version 2.70, it will make children cry. Sobbing, they will repeatedly press ctrl+z to no avail, believing that their character's bone is gone and their animation is ruined forever.

Thank you, @Thomas Dinges (dingto). I tried the "=" key but it has no effect.

There is a note on the wiki:

Thanks, @Joshua Leung (aligorith)! I believe you if you say that this issue is more trouble than it is worth to fix.

That sounds like a fine solution. Thanks, Everyone!

P.S. Here is the attached example. Almost forgot!

What if "time offset" were another modifier in the stack entirely? That way, it could be added as part of a chain with any modifier or keyframe animation. You could achieve @bassam kurdali (bassamk) 's effect and many others without adding too much more clutter to one modifier.

I agree, @Brecht Van Lommel (brecht) , but which scene's camera data would the output node use? You would still have the same issue as with the Defocus node, in that the node is taking invisible inputs (i.e., camera data) that are not exposed to the user.

@Lukas Toenne (lukastoenne) , That's a very good observation.

@Brecht Van Lommel (brecht), I wondered about that right after I reported this. That "feature" would be useful for just such a thing, but it seems wrong to make it ambiguous to the user.