Multiple installs would like API access to edit Almanac bindings.

PHI145 discusses almanac.service.edit not working because of the "objects which require an implementation" issue described in D18849 and linked objects. That dealt with this problem in Drydock blueprints. The fix there wasn't completely satisfying but seems generally reasonable. This is likely straightforward but just fixes the endpoint in the web UI and allows service creation, neither of which anyone actually cares about too much.

PHI145 and PHI473 both ultimately want API access to bindings. The major wrench in the gears here is that bindings aren't particularly modern internally.

A lurking issue is that properties both aren't modern and are defined in a very informal, fairly ad-hoc way. But a saving grace is that the upstream only defines one actual service property and zero binding properties -- even though it uses binding properties -- so this is possibly mostly a fix-forward.

This probably looks something like:

• Implement the "thing that requires another thing" support for Services.
• Move Bindings to EditEngine and ModularTransactions.
• Figure out what's going on with Properties.