The fleetctl start command sets the desired state of a unit to "launched" (that's a fleet state, not a systemd state) and waits for the unit to be scheduled and the target machine to publish systemd state. fleetctl does not look at the contents of this systemd state.

The systemctl start command acts more like an RPC command, sending a StartUnit message over dbus and waiting for the created systemd job to finish.

We have a clear usability problem here. Users expect fleetctl start to be equivalent to systemctl start (#1019). This inconsistency is also preventing us from moving forward on adding a fleetctl restart command, which should reasonably act like systemctl restart (#961).

Assuming others agree that this inconsistency is a problem, I see only one real path forward. fleetctl start needs to watch for the unit to actually start successfuly in systemd.