Further thoughts: it would not be entirely out of scope to implement a warp-to-plane alignment, and that would be possible, though likely not in Cauchy; but since many conics-based tools rely on celestial targeting, it seems nice to still allow it. We have been trying to unify stock features with our reference frame selection, and it seems like it would make some sense to give a meaning to targeting a celestial (targeting a vessel obviously has an effect). This requires some thinking so that the reference frame selection remains somewhat consistent; here is a proposal, it may have some confusing interactions that I am missing, so comments are welcome.
The domain of stock (or @ferram4); we do not orient the navball nor display the velocity ourselves, the reference frame used for trajectory plotting remains whatever is selected in our UI.
Overrides the selected reference frame: the plotting frame becomes the target LVLH frame, where the reference body is the one selected in our UI. the navball is oriented according to the plotting frame. The active vessel's speed is displayed in the plotting frame if the active vessel is managed by Principia.
The plotting frame is selected in our UI; the navball is oriented according to the plotting frame; the active vessel's speed is displayed in the plotting frame if the active vessel is managed by Principia.
The speed mode is now fused with the frame type selection; we display the speed even for unmanageable vessels; the navball is always consistent with the plotting frame; we always orient the navball.
This speed mode is set if and only if the selected reference frame type is body-centred, body-fixed: switching to it sets the reference frame type; switching back to Orbit speed mode sets it back to the last non-surface type (fallback to inertial if the last type is invalid). We display the speed, and orient the navball.
The @ferram4 exception: If the active vessel is in an atmosphere, switching to body-centred, body-fixed (either in our UI or via the navball) sets the reference celestial to the one with that atmosphere; this is reflected in our UI; moreover, we do not override the speed display. We still orient the navball (this should have no effect). The reason for this is @ferram4's custom speed display, which overrides the surface speed display when in an atmosphere: we do not want to override that, and we want to show a navball and a plotting frame consistent with the speed shown.
Overrides the selected reference frame: the plotting frame becomes the target LVLH frame, where the reference body is the one selected in our UI. the navball is oriented according to the plotting frame. The active vessel's speed is displayed in the plotting frame (unconditionally).
Any plotting frame can be selected; the navball will follow this selection; the speed display is handled by stock. This is entirely unsatisfactory, and we should fuse this with the above at some point.
The plotting frame is selected in our UI, its type is one of the three non-surface types; the navball is oriented according to the plotting frame; the active vessel's speed is displayed in the plotting frame (unconditionally).
Same as current at master.
If the target is a celestial T whose parent is P, the plotting frame is overridden to T-centred P-aligned, unless the currently selected celestial S has T as its parent, in which case the plotting frame is overridden to S-centred T-aligned. This is an override, not a switch, so if the target gets deselected, the plotting frame will revert to whatever it last was. Further, we should display ascending and descending nodes for the plotting frame in that case (might not make it into Cauchy).
We will first take the example of launching from Earth into the plane of the Moon. We target the Moon. This allows us to use MechJeb to warp to the launch window, or, setting the speed mode to Orbit, to see the orbit plane (the frame gets set to MCEA) and thus the launch window. We then set the speed mode to Surface, which sets the plotting frame to ECEF (bCbF because Surface, Earth because of the @ferram4 override). The early ascent happens in ECEF, then KSP decides on its own (as in stock) to switch to Orbit mode. At this point, the MCEA frame is displayed, so we can see whether we lie in the right plane. Plane matching can be done using the information (out-of-plane Δv) shown on the nodes. The frame is already probably right for transfer planning, if MCMF is desired for impact location planning the moon can be selected in the UI and the navball can be switched to surface (we are out of the atmosphere by now, so the @ferram4 override no longer forces us back to ECEF). If MCI or EMB are desired, the Moon must be untargeted. I do not see a reason to use MCI at this point, and if we are using EMB we are probably interested in Lagrange points and the like, not in the Moon anymore, so it makes sense to untarget it. Once reaching the sphere of influence of the Moon, KSP will forcefully untarget it (KSP forbids targeting of the orbited body), insertion and landing can continue as usual.
When launching from the Moon for Earth return, we set the reference frame to MCMF (the Moon is selected, the navball set to Surface mode). We target Earth--- Oh crap, we can't do that.