It sounds like we're talking about slightly different things.
The find-scheme-libraries! procedure is supposed to be called by an end user who has a bunch of libraries that they potentially want to import. It's not intended to be used during the import process, which works pretty much as you suggest, except that map from library name to pathname is created by a previous call to find-scheme-libraries!.
The loader's job _is_ simple -- when asked to import something, it looks up the required libraries and their dependencies in the in-memory database, then loads them in a dependency-mediated order. If one or more of the needed libraries aren't in the database, then an error is signaled and nothing else happens. The database itself is static at load time (modulo perhaps adding the content property that is deliberately not set for unloaded modules). I will probably add some additional checks such as making sure there have been no relevant changes since the pre-registrations were saved, but again that will simply cause the load to error out rather than try to repair.
It's the end user's responsibility to make sure that any libraries they want to import are pre-registered in the database. If changes are made to the library files are made, they need only re-run find-scheme-libraries!, which will update the database with the new information. The in-memory database isn't a cache -- it's the source of truth, as defined by the end user.
It's true that the deregistration of old versions of libraries aren't guaranteed to be correctly removed by the process, although it handles many cases now. That can be improved with more work; keeping track of registered pathnames better, etc. But ultimately we have to trust that the end user won't do anything that causes confusion, such as use symbolic/hard links. We can protect against that but not prevent it.