We are aware of the permission requirements you describe and that's exactly how we set it up. Yet in the same session the first of the following statements works and the other doesn't:

SELECT * catalog_b.schema_b.view_b; --works
SELECT * FROM IDENTIFIER('catalog_b.schema_b.view_b') --fails with "User does not have USE CATALOG on Catalog 'catalog_a'. SQLSTATE: 42501"

The only difference being the use of IDENTIFIER(). To me that is a strong hint to this problem being specific to that function.

For example, consider the implementation of IDENTIFIER() would rely on a mechanism that is listing all related UC objects in the background to find out which one to reference. If that code would run under the caller's identity (which does not have any permissions on that other catalog), then that would perfectly explain the behavior we are seeing.

That would be a bug to me, though. Functionally, both statements above are exactly equivalent and should simply do the same thing.

And it would be a case of a leaky abstraction. The caller should not see the name of that other catalog ('catalog_a') in the error message, if that identity does not have any permissions on it.