The discriminator column could be literal. But the VALUE needs to be dynamic.

Yep, that's why I said

For sure you'd have to look at the EntityPersister and CollectionPersister contracts as those handle generating most of the "fragments" of SQL that get pieced together. These changes would have to account for the internal cache of SQL statements kept on each of these impls (mostly through AbstractEntityPersister and AbstractCollectionPersister).

If SQL literals are used we cannot cache these statements. Well, we could but we'd need to cache them one per-tenant and I'd rather not go that route.

I think it's OK if in V1 we can't filter native SQL queries - so long as we had a consistent way to parameterize those too so that the author/developer could change those queries to support multi-tenancy in a way that's consistent with the parts we can automate.

Sure, because that's the harder problem to solve

Ultimately I think that needs to come back to a Dialect-provided SQL parser whose AST we could then use to inject any needed tenant filtering. Maybe we'd supply parsers for the most common dbs, and I only say that because there used to be parsers for many of the specific dialects for these dbs on the Antlr site.