Looking for feedback on those topics. If you have opinions or concerns feel free to voice them :)

1. Moving backends?

For 1.80 we are currently considering moving the examples/imgui_impl_xxx files to backends/imgui_impl_xxx (or backends/imgui_backend_xxx even?). Initially those back-ends were added to examples/ as a way to suggest that there are easy to adapt or write for custom user/engine needs. It was also a way to lower our responsability "this is just an example, tweak it".

Nowadays:

• The backends are for most rather solid. For API like OpenGL, they handle a bunch of cases of saving/restoring random OpenGL context which is very useful for new or casual users. Generally speaking I would want us to keep improving those back-ends if there is a reason too.
• Supporting multi-viewports from the docking branch generally requires more involvement from back-ends writer. Whoever uses default back-ends can benefit from multi-viewports instantly (vs custom back-ends often don't).
• The fact that they are stored in examples/ DOES have the expected effect of passively encouraging my-custom-engine people to rewrite their own. I think this is now becoming counter productive, since it means some people are spending 2-3 days integrating dear imgui for the first time instead of the 30 minutes it should take, because they insist on reimplementing a back-end. When they do, their back-ends often have subtle issues they don't immediately notice. I've seen countless cases of people spending time reimplementing a back-end for their lightweight abstraction, only to scrap it and use the default back-ends eventually. It's absolutely counter-productive because 1) they would be better off starting with available back-ends, even if it means using multiple backends for portability (we should encourage/document that better: if a custom-engine is aimed to be portable, people can use multiple default backends!). 2) anyone can decide to rewrite the back-ends AFTER THE FACT and after they are acquainted with dear imgui, but there's no reason to do it day one.

We're only talking about moving files here... I'm mostly interested in the psychological side effects of this change...

It should be a small, easy to document and convey, one-off project breaking change (e.g. change a file-path). Currently evaluating if it'd be a good occasion to break something else (e.g. explicit back-end context creation).

2. New source file: imgui_tables.cpp?

For 1.80 we are aiming to merge the tables branch into master.
Tables have been developed in imgui_widgets.cpp but seeing that it is now becoming a large file, I was thinking it would be sane to split it and move that code in imgui_tables.cpp. We will also aim to fully rewrite the git history so all tables developments goes directly into imgui_tables.cpp.
If possible I would like to avoid different branches using different files, in order to facilitate switching projects, so I would only do this change just prior to merging in master.
Similarly, for 1.90 (hopefully) I think I'd like to move docking code out of imgui.cpp and into imgui_docking.cpp