Yes, there is a provision to add rollback scripts which will be applied whenever you're doing a rollback. Basically, every migration script in V2 consists of two parts - an upgrade script and a downgrade script. As of now the user interface only allows you to add an upgrade script, but the engine code handles downgrade scripts as well. Let's say you wanted to rollback your database from v3.0 to v2.0 (the previous version), the migration engine would then look for the migrations scripts that had been applied as part of the upgrade from v2.0 to v3.0. It would then pick the corresponding rollback scripts and apply them in order before the SQL Compare Engine rolls back the rest of the schema change. As an example, if you're doing a table rename in your migration script, you could include a rollback script that would do the reverse of the rename. Let me know if you need any help with adding the rollback scripts.
Could you help clarify what you meant by whether this will break the existing rollback mechanism? The mechanism for SQL Compare rollback is still the same. The only difference here would be that the migration script rollbacks would be applied first.
The TempDb setup is not mandatory. MigrationsV2 by default tries to connect to LocalDb if you have one installed. I think that would explain why this still worked for you.
Regarding your last point, we don't have an ETA yet, but we're working actively towards it. I'll keep you up-to-date on this.
In one of your previous comments you mentioned that "A check-in a command line script will execute and update the changes to the 'Test database'" from the TestBranch. Is it fair to assume that you're using the SQL Compare command line to achieve this? Also, I'm very keen to know how your environment was setup when you evaluated the beta. Let us know if you have any other feedback from your evaluation experience.