I don't want to block the release, but in my experience g.extension not working correctly is something that leads to a very frustrating user
experience on Windows, so would be great if this could be solved before.
Problems that are caused by the addons themselves should obviously not
be considered blockers of a release, so we should focus on the issues
directly caused by g.extension.IIUC, they all are caused because the addon is either a toolset with
several modules, or there are library files in the directory or in
subdirectories (e.g. i.segment.hierarchical and r.estimap.recreation).
The relevant zip file does contain all necessary files for running the
addon, so it is g.extension that is looking for info that it shouldn't
look for.
OK, here is a PR to address this issue on Windows:
https://github.com/OSGeo/grass/pull/1565
I've tested this PR; it works in winGRASS; PR can be merged.
and see https://github.com/OSGeo/grass-addons/issues/525#issuecomment-835489716
for an example of looking for a needle in a haystack ... ;-D
a single character which doesn't match the file encoding is able to crash g.extension in winGRASS, though not in linux.
there is another PR for more lazy imports in some addons; also this PR should be merged.
to sum up with these PRs, g.extension addons experience in winGRASS should be improved now. 
then ready for an RC.
best
helli