Thank you for the amazing work reviving this @thedmd.
Some quick thoughts (and we can discuss details in our chat later):

Given the simplified specs for "full reload" this looks good, but I would like us to make sure we have a sensible path for when we'll want to transition this to the fuller version (https://github.com/ocornut/imgui_private/issues/3)
They are two main difference:

1. Textures may have to be uploaded in _Render (to support dynamic glyphes).

I think it may be simpler/favorable to only try to upload at the end of the frame rather than also support the optimal timing for the initialization scenario or rare best-case scenario where we can do a full upload around NewFrame().

So presumably, the first ImplXXX_RenderDrawData() function call of each standard backend may be the one doing the upload if required.

(Advanced: to reduce latency on high-performing application, we want to permit custom backend to start uploading the texture after EndFrame() - without waiting for Render() or even ImplXXX_RenderDrawData(). This shouldn't be a problem at all from ImGui:: point of view. To test this scenario, I imagine some default backend may want expose a ~ImplXXX_UpdateTexture function which ImplXXX_RenderDrawData would call is texture is dirty, but we allow user to call that function. It's not 100% required that all default backend support it, but I still it would help convey the possibility and and test the scenario)

Timeline for Frame N:

• Old/existing backends will still attempt to build the atlas in ImplXXX_NewFrame() - before ImGui::NewFrame() - and then upload texture. Should not be a problem.
• ImGui::NewFrame() will need to build the atlas data if dirty because we need glyphs UV ready. (with new backends, ImGui::NewFrame will be the first piece of code updating this, with old backends, this is likely to be already built). Technically we don't even need the pixels to be rasterized at this point (but it's simpler to rasterize them).
• As a result of forcing the atlas build in NewFrame(), the very useful assert IM_ASSERT(g.IO.Fonts->Fonts[0]->IsLoaded() in NewFrame() doesn't make sense anymore. Instead we can try to replace the assert with one that checks that if the texture was dirty on NewFrame..EndFrame N, someone should have called XXXGetTexData by the time NewFrame N+1 is called (because with new backends the right time for texture upload will be after ImGui::EndFrame or ImGui::Render)
• Anytime after EndFrame(), the backend is allowed to get texture data and upload it. In default backends this will generally be done in ImplXXX_RenderDrawData().

2. We'll want (in future) to notify the back-end of partial update.

This was partially (and bit awkwardly) covered in the original version. I don't think we need to have it 100% ready now but we should explore the proof of concept API at leaast, to ensure a smooth transition from this PR version. Maybe we can even come to the realization that we can implement the API completely today, and have the back-end not fully honor the partial update, or something (not sure that's a good idea).
Maybe we need to separate into two flags ImGuiBackendFlags_RendererHasTexReload and ImGuiBackendFlags_RendererHasTexPartialUpdate ?

Unrelated (minor): why does ClearInputData() remove CustomRects.clear() and PackIdXXX clearing?

1. Textures may have to be uploaded in _Render (to support dynamic glyphs).

Incremental atlas baking branch i am working on updates font atlas texture outside of imgui frame. Which means that for very first time an unknown glyph is encountered, a fallback character is rendered. It is invisible to naked eye at 60fps so probably is good enough.

Which means that for very first time an unknown glyph is encountered, a fallback character is rendered. It is invisible to naked eye at 60fps so probably is good enough.

Sorry but this is not good enough.

We're working out a scheme with @thedmd to push this forward, it's going to work out :)

Turns out rasterizing glyphs immediately wasnt that big of a deal. I am not quite sure if locking font atlas during frame is warranted. It rebuilds just fine, granted it happens on main thread. The only issue i noticed is that build step intends to clear texture id, which is undesirable as ImDrawList::AddText() does IM_ASSERT(font->ContainerAtlas->TexID == _CmdHeader.TextureId). I am not sure whether this detail was overlooked or not, but apparently if we request font atlas update during this frame and we would like to use new atlas by the time this frame is rendering on GPU - we will have to update ImDrawCmd::TextureId of all draw commands with a new texture id.

I am not quite sure if locking font atlas during frame is warranted.

Probably not anymore.

We will have to update ImDrawCmd::TextureId of all draw commands with a new texture id.

Yes this is why we changed all the render loop to use draw_cmd->GetTexID().

Well, status table went out of date after introducing ability to update texture mid-frame.

Technically we also moved this to a private branch for now (but thedmd: you could push that branch back into your public copy)

I pushed private branch here. I expect most backends will not pass build test. DX9 however should build fine. This is still work in progress.

Work on long-standing PR has been finished and is part of the current WIP branch dynamic_fonts (#8465). Even though the branch is not merged yet, it should be this spring.

This is a mixture of early backend work from @ShironekoBen, and ongoing improvements/rework/redesign from @thedmd and me. New protocol is fairly different from the things we drafted back then, but solves the same problem.