OK. Will close this one out, then.

Should a mapping defined in the pseudo constructor be able to be used/expanded immediately after it is declared?

No

I guess, perhaps it’s possible if I could somehow point the actual application settings at the literal this scope of the application.cfc file prior to running the constructor, but that poses a number of interesting issues. As it stands, the pseudo constructor runs first, then we extract the this scope to register the application settings for the remainder of the request. So the context’s config object doesn’t know about this.mappings right away. I’m not sure how that would affect ORM though as ORM shouldn’t load as part of the pseudo constructor. It should load after that is finished.

I’ve worked around the ORM module issue with path expansion, by storing the mapped path as the FQN in the EntityRecord. So I guess this story becomes more of an issue of:

Should a mapping defined in the pseudo constructor be able to be used/expanded immediately after it is declared?

I guess I need more to go on here as I’m not sure what exactly the issue is. expandpath() will always use all the mappings it gets back from the context’s config struct. If there is ORM code running outside of a request, then it wouldn’t have any mappings which come from the request itself, so this could simply be a matter of the ORM code using the wrong context to execute code. For example, if the runtime context was used, it would only “know” about server-level mappings.

Yes please. I’ve tried to write a reproducible test case, but have been playing whack-a-mole