Some more thoughts from my side on this.
Regarding whether we are using direct or brokered semantics to send commands (and replies); as already mentioned, we don’t have a mechanism in Hono to know if device is connected or not. And even if we have a lifecycle service for that, there is always a window when a device can go offline during the command delivery.
So to me it looks it should be a feature of a device or Hono as a connectivity platform to choose which of these mechanisms will use in the particular case. But in nutshell, we can have a “best-effort” command, that will try to use direct addresses and fail immediately if that fails and “timed-out” commands that use queues to allow commands to be delivered and executed in some time window. For timed-out commands we can provide even multiple feedback statuses in the API, like command delivered, started executing, executed and similar to allow the app to track of the progress.
In my opinion we should keep focus of Hono APIs just on communicating with a particular device in some of these fashions, but provide flexibility to use external services (life cycle, digital twin, etc.) so that apps can achieve desired overall functionality.