Sorry - one more thought: it would be important to preserve the variable syntax when deploying changes from the database to the SSDT project. If the other way around, it would be equally important not to make a variable out of the distinct reference in the database.

I'm trying just now to use SQL Compare to update my SSDT project. For a changed script where variables are in play, I'll have to manually change the true updates (some VARCHAR arguments) so as not to have my variables overwritten.

Yes, I think something like this is required for working well with SSDT projects. Showing up a difference because a project object uses a variable while the database equivalent does not is essentially 'noise' - a false positive.

However, the ideal could be for SQL Compare to recognise the variable syntax and mark the two objects as equivalent as long as what follows matches on both sides. This way, there would be no need to select another option. I guess the feasibility of this depends on whether SQL Compare recognises that it is dealing with an SSDT project (versus a collection of scripts) and can apply different comparison logic accordingly.