When naming views in the virtual layer, SQL Mesh supports only limited options.

Why this matters
When existing projects are migrated into other frameworks, one of the biggest risk factors is breaking dependencies. Because of this, forcing a different naming convention onto users creates a high barrier to entry for projects that don't already follow SQL Mesh conventions.

Current behavior:
Views in the prod environment are named like this:
{database}.{schema}.{model_name}

For lower level environments, the behavior depends on environment_suffix_target
environment_suffix_target = database
Yields: {database}__{env}.{schema}.{model_name}

environment_suffix_target = schema - (default)
Yields: {database}.{schema}__{env}.{model_name}

environment_suffix_target = table
Yields: {database}.{schema}.{model_name}__{env}

This is unnecessarily opinionated and can be a blocker for companies that already have a working setup and are considering migrating to SQL Mesh.

Compare this to dbt. It allows mostly full naming flexibility by letting users override the macros generate_schema_name() and generate_database_name(), where you can inject environment variables to construct any arbitrary output string.

Desired behavior:
User has full flexibility.

Example 1:
prod: {database}.{schema}_prod.{model}
dev: {database}.{schema}_dev.{model}

Example 2:
prod: {database}.prod_{schema}.{model}
dev: {database}.dev_{schema}_{ENV_USER_NAME}.{model}

Conclusion
SQL Mesh could benefit a lot from introducing a similar degree of flexibility. Out-of-the box behavior can remain as-is, but users should be able to override it if they need to.