Exposing single-shot events with miniconf currently looks like:

• expose a miniconf boolean flag struct member
• set it true
• in the application recognize the single false->true change, act on it, records that it has acted on it
• set it false before making any other miniconf change

This has a couple of downsides:

• No support for long-running/expensive commands/changes
• No support for returning results/responses
• Fragile sequencing

The potential enhancement is to implement a specific miniconf endpoint that supports request-response patterns.
A hot incoming request would be stored by miniconf until executed and cleared by the application, at which point the corresponding hot response is stored by the application, and serialized/sent/cleared by miniconf.
The data structure looks like a pair of single-entry queues, one for request, the other for responses. There is likely an implementation already. It would be useful to be able to split it into miniconf and application halves to make it lock-free.

Open questions:

• Constraints on request/response payload
• Location and correlation for response publication
• Ignoring/skipping during re-publication
• Namespace separation from settings