There is a reason why the CreateConfiguration callback provides both a GUID and service_path; it may very well be invoked before the NetworkState cache has been updated. In general, configuration UI shouldn't be using NetworkState; the NetworkState class exists as a convenient cache for, e.g., showing the list of available networks.

Scanning through arc_net_host_impl.cc, I am guessing that this is the scenario you are running into (it isn't entirely clear to me from the description above, a lot of context is missing):

1. ArcNetHostImpl::CreateNetwork() is called.
2. ArcNetHostImpl::StartConnect() is called before the NetworkState cache is updated by Shill.

Ideally the client code (arc) should wait until the configured network shows up in GetNetworks() before attempting to connect (I think that is option 'c' above?).

Barring that, we could keep a separate GUID -> service_path map in ArcNetHostImpl for configured networks (option 'd').

I would be wary of modifying NetworkState for these purposes. The current design has NetworkState reflecting Shill state, so modifying it separately would be challenging to keep in sync.

(Note: The plan was to modify Shill to use GUID instead of service_path for Connect and other operations, however the Shill team got pulled away to other things before that could happen. An alternative approach would be to modify NetworkConnectionHandler to take GUID instead of service_path and maintain a separate GUID -> service_path map that Network*Handler would use, effectively option 'b' above).

For option (c), which observer/callback would you recommend using to figure out whether the new configuration will show up in GetNetworks?  Is OnNetworkChanged the best option?

I guess this means we'll need to maintain a list of "pending configurations" in arc_net_host_impl and query whether each one exists from the observer callback?

See NetworkStateHandlerObserver::NetworkListChanged