I noticed that in the latest Blender version, Lasso Select is now available as a menu item. This solves the terminology problem: we can now refer to "Select Box/Circle/Lasso" as the "Toolbar selection tools", and to "Box/Circle/Lasso Select" as the "Menu selection tools." I updated the patch accordingly.

You're right, it does get saved - you just need to know where. I couldn't find it, and the few posts I found on the topic mentioned that the "saving" part is a lie anyway as it's really just a rename of the latest autosave, which might not contain the latest changes. Those posts are old, however.

Given the somewhat unconventional nature of the "non-toolbar" selection tools, I assume they go back to Blender's first versions and were later more or less superseded by the "toolbar" ones (similar to how right-click select was changed to left-click). If that's correct, maybe the naming distinction could be made based on that? E.g. "Original" vs "New', "Legacy" vs "Modern"...

That's fair. Thanks for considering it!

Personally I'd say that the manual should be descriptive of how Blender behaves, not prescriptive of how it's supposed to be behave. The software should evolve to do whatever makes the most sense, and the manual should follow - wouldn't you agree? And from my point as an (admittedly new) user, I felt it would make sense for keyframe deletion to be consistent with keyframe creation. If the "I" shortcut can create a Power keyframe, "Alt-I" should be able to delete it.

The Ctrl button, which is supposed to toggle snapping on the fly, also behaves inconsistently.

By default, the timeline only shows keyframes for selected objects. When looking through the camera as in your screenshot, you can select the camera by clicking on the dashed border in the 3D viewport that separates the "bright" area from the "dark" (or you can just select it in the Outliner). The border will then turn orange, indicating the camera is selected.

On a side note, I noticed that the confirmation message reads "Delete Keyframe" (singular) even though it presumably deletes multiple keyframes most of the time.

In general, I also find it a bit strange that while predefined keying sets create keyframes for the selected objects, custom keying sets create keyframes for specific objects regardless of what's selected. Would it make sense to allow custom keying set properties that have no target object and consist only of a data path (which then gets resolved at keyframe creation time based on whatever is selected)? If yes, I could create a separate ticket for that.

Thank you for the quick turnaround. It looks like the commit doesn't include a fix for the inconsistent context menus (which, admittedly, weren't really brought forward in this ticket); should I create a separate ticket for those?

The difference between "Clean Channels" and "Delete Channels" is that "Clean" only deletes channels that contain no useful information (namely, channels whose keyframes all have the same value). In the example above, "Delete" deletes all the channels, but "Clean" leaves behind the "Z Location" channel. So in that sense, I wouldn't say "Clean Channels" is a bad name - at most, it could maybe be moved from the "Key" menu to the "Channel" menu, and be made to work with the selected channels rather than the selected keys.

Some suggestions from my side: