As an app developer this strikes me as the right approach. But having said that, I wouldn't actually need this feature because Briar already uses __OwningControllerProcess to shut down Tor if the control connection is closed. I imagine the same would apply to any app that manages its own Tor process - so this feature would only be useful for apps that share a Tor process with other apps and communicate directly with it via the control port, rather than indirectly via a controller such as Orbot.
This feature is going to change how tor controllers operate... and whether the tor controller is a separate process or an API that the application uses seems to have been overlooked in this last statement of yours. Here's an example of what I mean; In the case of Twisted Python applications... olde apps written a decade ago are made to work with Tor hidden services without a single line of code changing... because the endpoint is dynamically loaded and the controlling of tor is abstracted by this Twisted endpoint.
pip install txtorcon && twistd -n web --port "onion:80" --path ~/public_html
In this case... can twistd be said to manage it's own tor process? It certainly does not contain any Tor specific code whatsoever. It is managed in the same process but the details are abstracted away by the txtorcon controller API.
Furthermore it is not limited to apps that share a tor process with other applications... Perhaps the computer has multiple instances of tor running; the Tor controller could be setup to connect to any of these control ports. This is an observation about a deployment issue more so than an API issue.
However, it seems like in the case of applications which are not HS-specific this will necessitate keeping another process running just to keep the HS alive.
responding to Leif's comment above:
This seems like a false statement in the context of using txtorcon with this feature. The above txtorcon twistd example could be made to work with the tor control port and it would not imply "keeping another process running". Furthermore, the above example currently relies on txtorcon launching it's own Tor process which I think is convenient but not so good for "security isolation"... and implies ambient authority, that is, why should the python process have that much control over the tor process? The python app only needs the privilege to create and remove it's Tor hidden service (principal of least privilege ftw).
Dormant processes are essentially free, so does this matter?
Yes, it seems like it doesn't matter much.. The local connection from the tor process would fail to connect to the local service. I'm not sure if there are other implications that are more important than this.