…er use cases.

This looked like a low hanging fruit. This allows setting physical schema override on a per model basis for power users who need it. Users are not likely going to start footgunning themselves with this any harder or faster than power users trying to fudge around with physical_schema_mapping for what would otherwise be one-off use cases for a specific model (for whatever the reason may be).

Furthermore, in theory, you can make any one-off physical table in the catalog a sqlmesh managed table with no copying or renaming using this in conjunction physical_version and forward only.

One good example I have are that we have these data marts. In them, only 1 table is a mission critical licensing table that we would like to store separately from the rest. But we would still like the views in one schema.

# say you want all these env views in mart_sales, but for one model, you need to store its physical snapshots somewhere specific
mart_sales.table_A -> sqlmesh__mart_sales
mart_sales.table_B -> sqlmesh__mart_sales
mart_sales.historical_financial_metrics -> physical_schema_override -> mart_sales_historicals_no_delete
mart_sales.table_C -> sqlmesh__mart_sales