It's not there now but I suppose it makes sense to introduce such an option along with a path to the PHD2 executable to run when PHD2 is selected as the guider. But it also has to check it's not already started.
I've spent some time looking at Voyager after a trusted (APOD winning) friend recommended it and there's a lot to like about their approach - some of which addresses ideas like this and more when it comes to starting up external apps (in my case, TheSkyX, as I use the internal guider with EKOS) but in their case relies on PHD which they startup for you.
It's a Windows only app so there's no chance I would consider it, especially given that Stellarmate/INDI is making huge progress and has the benefit of being open source/community friendly.
The benefit they have is a relatively fixed model for knowing where everything is running and of course it's not true client/server like INDI/EKOS which has a more complicated set of use-cases to deal with.
Long way of saying, it's a great idea - since I've started preparing to go fully robotic/remote (my telescope will be 1000 kms away in Siding Springs), I am starting to appreciate the need for more automation and "business logic" being built into Ekos Scheduler. (including an IFTT type logic/workflow builder).
Starting up (and monitoring the state of) PHD2 would be just one of the related modules - same goes for ensuring that remote device servers are started up and managed. eg: I have my Flat Man and dome controller running on a separate Raspberry Pi to the main imaging RPi that rides on the OTA - ensuring that this whole ecosystem is up, running and stable - including retrying to get the system back o working rather than just exit(-1) and stopping a recoverable session has increasing merit to me - I'm just not skilled enough to code it (yet).
The following user(s) said Thank You: Jasem Mutlaq