Opening this as a major follow-up of #1818560: Change notice: Convert taxonomy entities to the new Entity Field API at webchick's request.
Right now, path.module has very specific storage and form alter hooks that integrate with and support nodes and taxonomy terms.
Previous attempts tried to make a path alias a field and support all entities through that. That has been blocked by UX issues.
The mentioned issue introduced a PathItem class as all data on an entity now needs to be explicitly defined. It did that add that field only to taxonomy terms as everything more would have lead to more refactoring not related to the conversion, which was a big patch already. We do want to use that to generalize support for all entities, however.
Two steps are relatively obviously towards that path:
- Use the class for node as well
- Use hook_entity_*() hooks instead of hook_$entitytype_*() (Sooner or later, that will also move to methods on the PathItem class
After that, I'm not 100% sure yet:
- How do entity types define that they want a path alias field? Possibly just define it themself, just like entity types now do with language? That pattern explicitly chosen to not make core entity types special and allowing contrib to do it in the same way..
- How do the form parts happen? The language stuff currently relies on some tricks to not fail if language.module is disabled. And we also want to keep pathauto in mind, which wants to extend everywhere the path UI is exposed on an entity. If we can make #1950632: Make formatters and widgets work on nonconfigurable fields happen (and we really want to), then the non-configurable path field could have a corresponding widget that would show up if the field is enabled and not if it's not. And pathauto could replace it with a different widget.