To be fair, you ask some interesting questions which I am not 100% sure on, and it appears a lot of other experienced users are not entirely sure either, the remapping process adds a straw that tips easy understanding into the brink. (As a developer (but not on KiCad) this raises flags about the UX which I would try to address if it was my code, but it isn't).
Firstly, some sensible, practical advice that doesn't imply any moral judgment, pointing of fingers or anything : for people who just want to get stuff done but still with latest features without having to understand in-depth KiCad internal behaviour, the sensible thing is to use a recent nightly build that predates the new symbol library table. Wait until the code has been fixed, tested and polished some more and come back to it when a) it works better b) there is a wider understanding of the features and how to use them.
Short answer : "It depends".
Long answer: * (as I understand it)
To recap, the project cache lib is written when the schematic is saved. A copy of the symbols which can be found from the libraries that are on the library search list are written to the project cache lib. Note: the project cache can be incomplete or empty if symbols were not found.
The project cache lib is automatically added to the library search path when you open a project, if the project cache library file exists. The project cache lib is a sort of automatic, behind the scenes backup, but it can get broken. In particular, the project cache lib is overwritten with the current schematic symbols every time you save the schematic.
In the case where the cache symbol is not the same as the symbol found by library search, then the symbol rescue kicks in. The symbol rescue creates a new separate project rescue library which contains copies of the symbols in the cache lib (if selected by the user).
I think the fundamental historic issue is that the schematic can get easily detached from the original source libraries, without the user realising. There is no quick and easy fix, the symbol library table is a step on the way to an ultimate fix.
Really before remapping, you need to start with a project in a good state: the remapper can't really guess what to do if data is absent. I did think about writing a "schematic health checker", but never got around to it.
It took me several tries to get a good method of upgrading pre-v4 projects to v4, including library symbol changes and the switch to footprint library tables. It's quite a long manual process which would be difficult to automate. I expect the same to be true for the symbol library tables, I am not at all surprised there are teething problems with the new code and that people are having problems.