Expose listening socket status in status-get command or maybe add option to make bind-fails fatal

Currently, when Kea DHCP daemon starts up, something like this can happen:

2021-02-20T20:23:22.619 WARN kea-dhcp4.dhcpsrv DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: failed to open socket on interface kea, reason: failed to bind fallback socket to address 10.67.2.1, port 67, reason: Address already in use - is another DHCP server running?
2021-02-20T20:23:22.619 WARN kea-dhcp4.dhcpsrv DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: failed to open socket on interface kea, reason: failed to bind fallback socket to address 10.67.3.1, port 67, reason: Address already in use - is another DHCP server running?
2021-02-20T20:23:22.619 WARN kea-dhcp4.dhcpsrv DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic

Iirc it can also not bind sockets if there's no address on the interface, which can be quite common if there's some race condition on e.g. system startup.

These are warnings which indicate that dhcp service is not working and will never work until daemon restart or reconfiguration.

Reporting these as warnings is somewhat different from how most services work on unix/linux.
For example, if apache/nginx listening sockets are unavailable on startup, they will immediately exit instead of running in an unusable state by default.

It's understandable that multiple sockets can be defined (probably?), and binding some of these can fail, but I'd propose that expected/intuitive default behavior should still likely be to exit with a fatal error if any of sockets defined on startup are unavailable.
And in fact, Kea already does that with e.g. control sockets - any conflict there results in an immediate exit, but not actual service sockets, which I think is confusing and unexpected default behavior, though it might be documented, and hard to change in a backwards-compatible way at this point.

But regardless of that, I'd propose that there should be at least an obvious and simple way to query Kea for "are you actually listening on any sockets, or just failed to start the service?" question.
Maybe status-get command would be a good place to return list of listening sockets in, given that it seem to be a status of a very important daemon component.
My use-case for such query is to check whether Kea daemon should be immediately killed and exit with error from a wrapper script, if it fails to open service sockets after start or reconfiguration.

Is there maybe some other way to check this status or instruct Kea to treat such "warnings" as proper failures that I'm just not aware of?

Don't think I'm good enough with C++ and familiar enough with Kea internals to implement it in any upstream-useful way myself, unfortunately, but wanted to suggest it as a useful feature, or at least create a thread which maybe can be found if someone else also finds this behaviour counter-intuitive, with some kind of workaround suggestion or maybe a resolution.

Thanks for consideration.