Now that this is no longer a replay, does it make sense to return the route._loadedConfig instead if it exists or check if the route._loader$ is already complete? The callers of load here prevent this from being the case, but it might still be a good safeguard. What do you think?

Yes we need to return route._loadedConfig but as route._loadedConfig will only exist once route._loader$ is complete.
Currently it is the callers of load need to set route._loadedConfig themselves. which is a bit odd and and addressed in #36654

The callers are (possibly more)

• RouterPreloader.preloadConfig
• the pipeline of the routeGuard from ApplyRedirects.getChildConfig
• the pipeline of the ApplyRedirects.matchSegmentAgainstRoute

The first two have checks for route._loadedConfig and use that if available so load will not get called in these cases. The later is probably should be updated to but atm the check in load would prevent duplicate loads

private matchSegmentAgainstRoute(
      ngModule: NgModuleRef<any>, rawSegmentGroup: UrlSegmentGroup, route: Route,
      segments: UrlSegment[], outlet: string): Observable<UrlSegmentGroup> {
    if (route.path === '**') {
      if (route.loadChildren) {
+         const loaded$ = route._loadedConfig ? of(route._loadedConfig) :
                                          this.configLoader.load(ngModule.injector, route);
-         return this.configLoader.load(ngModule.injector, route)
-              .pipe(map((cfg: LoadedRouterConfig) => {
+        return loaded.pipe(map((cfg: LoadedRouterConfig) => {
              route._loadedConfig = cfg;
              return new UrlSegmentGroup(segments, {});
            }));
      }

      return of(new UrlSegmentGroup(segments, {}));
    }
    ...

Lastly in the delay between create and compete of route._loader$ we need to use the same observable if load is called multiple times. Which it can be as, in fact we have test that do this.
ie there can be a call from multiple of the load callers. In the test we have one from the call RouterPreloader.preloadConfig and on from the call through ApplyRedirects.getChildConfig

I absolutely agree that it's odd for the callers of load to set _loadedConfig rather than having RouteConfigLoader and I like the direction of #36654.

Since RouterConfigLoader isn't public API and neither are the callers of load, I'll leave it to you to decide which approach to take to ensure we aren't returning the already completed _loader observable:

• Handle it in the load function in the same manner the callers are doing by checking for _loadedConfig
• Update ApplyRedirects to not call load if _loadedConfig already exists.

We can then consolidate everything in #36654 or in another PR that omits the RouteConfigReady feature and only improves the DRY-ness (would be easier to land, as it's not a public api change).

@atscott Ideally I think we should put the test route._loadedConfig inside load, and move it setting to part of the load, but apply_redirects use the status of route._loadedConfig to avoid duplicating calls to the load guard.

Thus we'd need some another call to allow us prevent calling the guard twice. ie would probably need to be change to public API of Route!

So i propose: (basically what we have.)

• load : Allows overlapping calls and will only load once.
• load : decide what to do if the previous load is closed / finished and load called
  • throw
  • reload the module
  • just return the current loaded module, but dose this also sent event etc again?
• leave it up to the callers of load to manage checking of route._loadedConfig

Once landed look at improving setting of route._loadedConfig to be part of the loads. observable pipe (new PR based on #36654)

I added a check to ApplyRedirects.matchSegmentAgainstRoute and a test using this code path.

@pgammans - 👍 Agreed.

I think maybe you forgot to push up your changes to ApplyRedirects.matchSegmentAgainstRoute? After that's done, I'll run a final sanity check suite of internal tests and this should be good to go! Thanks for the hard work!