What problem does this address?

Part of #47786.

It's based on the observation I shared after studying the refactoring applied by @talldan in #47375 to use hide the experimental APIs with the locking/unlocking system. The comment is available at #47375 (comment):

One potential drawback to calling unlock on the entire data store exists. After a couple of refactorings, it will be impossible to tell which selectors/actions are experimental. In the case of promoting an experiment to a stable API, the unlock call will stay in place as there won't be any incentive to refactor the code. In addition, it's going to be difficult to tell whether this proxy can be safely removed without running the code, because several more than one selector/action could be experimental.

What is your proposed solution?

Two solutions were proposed by @adamziel in #47375 (comment):

1. Don't expose stable selectors on the unlocked store. Drawback: Now you need two useSelect() calls.
2. Use a prefix like __internal to make the difference apparent. Drawback: There's still a prefix.

I don't like either of these solutions. This issue could use a separate discussion thread.

@talldan commented on the idea (1) in #47375 (comment) with:

I don't think it'd require two useSelect calls, it'd look a bit like this:

const { public, private } = useSelect( select ) => {
  const { publicSelector } = select( myStore );
  const { privateSelector } = unlock( select( myStore ) );
  return { public: publicSelector, private: privateSelector };
} );

I responed to the idea (2) in #47375 (comment) with:

It might help if the prefix was automatically prepended by the lock call. Still, not ideal 😄