discussion: quitter's place in the library #415

From the review result:

Then I found, not in the docs, but in the examples from the repo the 'quitter' example -- pretty much exactly the kind of thing today we'd write using asio. [...] Looking at the code in the quitter example, well I wouldn't have guessed how to write that and the asio code would be more concise. So I think this goes to the heart of the question: why leave this stuff in if it's not really documented?

Source: Boost review result (conditional acceptance), Boost mailing list, September 2026.

The documentation half is already tracked (#409). This issue is the design half: is quitter a supported, recommended part of the toolkit, and if so what is the sanctioned shutdown pattern built on it?

• Keep and promote: document the quitter + signal pattern as the recommended pure-Capy shutdown idiom (depends on the outcome of the io_context/signals discussion)
• Keep as a low-level tool with the example as its documentation
• Remove, if the answer to the review's question is that it should not ship