What kind of feature are you missing? Where do you notice a shortcoming of PTB?

When first learning about PTB and particularly about ConversationHandler, it felt quite natural to me that there should be a per-conversation data store, or at least some kind of identifier to univocally identify each conversation.

Describe the solution you'd like

I would like to to have a per-conversation data store, available in callbacks called from a ConversationHandler, e.g.

async def some_conversation_callback(update, context) -> int:    context.conversation_data['some_key'] = update.message.text    return WHATEVER

This would be cleaned up after a conversation has ended (following all the usualper_* semantics).

Alternatively, a conversation identifier would be a viable alternative:

async def some_conversation_callback(update, context) -> int:    conv_id = context.conversation_id    context.bot_data[conv_id] = {}    context.bot_data[conv_id]['some_key'] = update.message.text    return WHATEVER

However it must be noted that this alternative has the downside that it requires manual cleanup in all final states (currently END and TIMEOUT), making this bearable but somewhat error-prone.

Describe alternatives you've considered

I have considered subclassing ConversationHandler and monkey-patching it by overriding all the relevant methods to associate a dictionary to each new conversation and destroying it when reaching a final state; and by subclassing CallbackContext to have an additional property to point to this dictionary. I have made a mock-up of this idea which works fine, but this is difficult to support because it relies on manually reviewing the internals of ConversationHandler after each library upgrade.

Duplicating the entire ConversationHandler implementation also achieves a similar result, while having the milder but still relevant downside that I won't get features and bugfixes automatically :)

I have also considered manually managing this per-conversation data storage manually in the handler functions of each conversation. However, as described above, the lack of a reliable way to get a per-conversation identifier makes this also somewhat difficult to support, because it requires at the very least to keep this per-conversation data login manually synchronized to the identity semantics of the chosenper_* parameters. The internal conversation key would be a suitable identifier, as by definition only one conversation at a time can ever exist at once for each conversation key. A UUID or serial number might be more useful for some user applications (albeit not mine!).

Additional context

Somewhat related to#2331