Schema Compare creates non-deterministic .sql file in SQL Projects when object names collide.

• SqlPackage or DacFx Version: 170.4.83.3+6b5a249e797735a88101d9bd17c72ef3fd0a0a87
• .NET Framework (Windows-only) or .NET Core: .NET Core
• Environment (local platform and source/target platforms): I am using SSMS 22 with an SDK-Style Microsoft.Build.Sql 2.2.0 project

Steps to Reproduce:

1. Have a database with a schema and user with the same name.
2. A brand new sql project that does not have the user or schema defined in a .sql file.
3. Run a comparison with your database as the source, and the SQL Project as the target
4. It should show an Add action for both the User and the Schema.
5. Apply the change to your local database project
6. You should see a new file under Security with the name of your user/schema
7. Inspect that file and you will see that it created a script for either the schema or the user, but not both.
8. Run the comparison again. If your file contained the schema, you'll see that the comparison wants to add user. If your file contained the user script, the comparison will want to add the schema.
9. Apply again
10. Inspect the script file again, and you will see it has switched from the schema create to user create script or vice versa.
11. This loop will continue indefinitely until you manually modify the script to contain both scripts separated by a GO or create two separate files with their own names that contain their own scripts.

The compare apply should either apply both scripts to the same file, or the files should not have the same target name. It would seem the cleanest to just put them into folders like Security/Users/ExampleScript.sql and Security/Schemas/ExampleScript.sql.

This may also happen with other object types, I just happened to run into it with the User/Schema combo.

Did this occur in prior versions? If not - which version(s) did it work in?
Unsure. This is the first time I have used the new sdk-style projects

(DacFx/SqlPackage/SSMS/Azure Data Studio)

SQL Server Management Studio 22.8.2+140.12023.21
SQL Server Management Objects (SMO) 18.100.11.28+78d2973eab5a47b182574a7c19c2faeedb3f41ff
Microsoft T-SQL Parser 18.0.4.0+85146cc66a685da2f1136c61e949e53a879d0bad.85146cc66a685da2f1136c61e949e53a879d0bad
Microsoft Analysis Services Client Tools 22.1.17.0
Microsoft Data SqlClient (MDS) 6.1.5+5bcf2003f4bab96e32aff1e2158393f9f4fcd1ed
Microsoft SQL Server Data-Tier Application Framework (DacFX) 170.4.83.3+6b5a249e797735a88101d9bd17c72ef3fd0a0a87
Microsoft .NET Framework 4.0.30319.42000
Operating System 10.0.26200

Reproduce the issue with SSMS 22.8.2, an SDK-style Microsoft.Build.Sql 2.2.0 project, and a database containing a schema and user with the same name. Inspect the generated files under Security and compare successive apply results; done when both objects are represented deterministically without alternating scripts or requiring manual edits.