there are some design elements I need feedback on.

IMO, answer to point 2 is No.
If it is presented as an option of custom transform orientation, it solves point 1.
When object is deleted, you just obtain current behavior with option greyed out.

What you are creating is not covering the need of permanence of a custom transform orientation.
This need will not disappear unless Shift S menu -> Cursor to Selected modifies rotation of cursor according to target normal.

Making this a new way to create custom orientation will be inevitably interpreted like an old way versus a new way, by newbies.
And people who try to teach blender will have to struggle to explain that is not the case.

So although we can imagine that has a own type, deleting the object could delete orientation too and that orientation would avoid to accumulate another list of custom orientations.
That is not solving problem of increasing list for current custom orientation that corresponds to a need that will last.
A purge button for custom orientation list is still needed. It could delete all custom orientation except active one.
If active orientation is a standard one, all custom orientations will be deleted.

As an option, you keep only current two lists of orientations in popover. As own type, you will have to create a third one.

This is a very useful addition. Here are some notes:

What should happen when a source object is deleted?

I think It should fall back to using 'self', if no object is selected or if the selected object is deleted (which would result in the same thing anyway)

Should this feature be presented as its own orientation type?

Yes. I think overall adding is as an orientation as you did is fine - keeps things compact and doesn't really add extra complexity.

If it is presented as its own orientation type, what kind of icon should it have?

Since it uses an external object, it should use the object icon, I think.

What should it be called?

I think this is a bit similar to using external objects for texture coordinates in shaders. There we just call it 'Object' and if the object ID pointer is not filled. it falls back to self.

Here's a small UI tweak. Before/After:

Other notes:

• The object ID field should only show if the orientation is set to Object.

Is this thing only valid for objects in object mode and is not concerning element selected (vertex/edge/face) selection in edit mode, too ?
Is there a solid reason for that restriction or an intend to extend it later ?

Anyways, if feature is not extended to elements in edit mode, that feature will be confused with current custom transform orientation.

@ronan ducluzeau (zeauro) It only works with object orientations. You could (theoretically) use a similar approach to create live geometry orientations from vertex groups, but you'd run into some ugly issues with modifiers.

The UI seems OK now, although I noticed one issue:

When you add custom orientations, the object ID field is placed below them. Probably it should appear always after the Object orientation, if possible.

I'd love to do something like this:

The orientation list is pre-formatted (even the separator is baked in), which means I'd have to add some more RNA items in order make the layout work. Wouldn't be too hard, if we're comfortable having three different orientation slot types (full list, just the static orientations, and just the custom orientations).

Are you thinking of a setup where there'd be a bone/object pointer in the TransformOrientationSlot struct, and the create_orientation operator would set flags for live vs static? I think I can see how the innards would work, but I don't have a clear picture of what that'd do to the front end.

@Campbell Barton (campbellbarton) IMO it could work both ways perhaps, but your suggestion doesn't really lend itself to an obvious UI or layout. I can't think of a great way to make a clear UI for that solution. Can you?