Session Level Shared AM is not what you think (or what the manual says!)

The JDeveloper manual gives the following definition for Session Level Shared Application Module:

If a view object instance queries data that depends on the current user, then the query can be cached at the session level and shared by all components that reference the row-set cache. For example, the session-level shared application module might contain a view instance with data security that takes a manager as the current user to return the list of direct reports. In this case, the cache of direct reports would exist for the duration of the manager's session.

After hours of failure, I found a discussion in the JDeveloper and ADF forum describing this issue.

In that post, Steve Muench offers the following explanation, (and subsequently has opened a bug on the Manual's faulted description):
The session scope shared application module is related to the ADFBC Session (SessionImpl) which cooperates with the Transaction object and is related to a single root application module. It is not shared across distinct root application modules. So, I don't believe that you're getting the sharing that you were expecting here.

The only thing that is shared across different root application modules would be an application-scope shared AM, or else something that the controller layer could make available like the HTTP Session, or one of the scopes like pageFlowScope which is managed distinctly from the number of root application modules used by the task flow.

Steve eventually points out that not all is lost trying to share view objects at a higher level than pageFlowScope:

If you can make the language a bind variable in the query, then you could use the application-shared AM. The shared rowsets are cached by unique bind variable combinations.

Since, I wanted to share my lookups for a given user based upon a given bind variable anyway, this will work just as I would like it to, and in fact slightly even better, because now it will be shared across all users, but still maintain a per user uniqueness. The manual describes how to do this pretty well, but you can ignore the other document bug (as pointed out in one of Avrom's Posts):

When viewing a data control usage from the DataBindings.cpx file in the Structure window, do not set the Configuration property to a shared application module configuration. By default, for an application module named AppModuleName, the Property Inspector will list the configurations named AppModuleNameShared and AppModuleNameLocal. At runtime, Oracle ADF uses the shared configuration automatically when you configure an application as a shared application module, but the configuration is not designed to be used by an application module data control usage

Go ahead and select the data control in question in the Structure Window for the DataBindings.cpx file and in the property inspector, set the configuration it should use to be the YourAppModuleShared configuration.