FireDAC schema changes: wrap DDL in one transaction or go forward-only with compensating scripts?

I'm designing a schema migration strategy for a RAD Studio (Delphi) application that uses FireDAC against more than one target DBMS. The goal is a rollback-safe upgrade path when a schema change fails partway through.

Two documented approaches seem viable. First, wrap the DDL in an explicit transaction using TFDConnection.StartTransaction / Commit / Rollback, which works cleanly on Firebird and InterBase where DDL is transactional. Second, use forward-only migrations via TFDScript, pairing each change with a tested compensating script, which is the pattern recommended for DBMSs like Oracle or MySQL where DDL triggers an implicit commit and Rollback cannot undo it.

The tension: transactional DDL gives atomic rollback but only on DBMSs that support it, while forward-only scripts are portable but demand disciplined, tested compensating changes that can be destructive. I'm also unsure how much TxOptions and auto-commit settings affect whether my DDL actually runs inside the explicit transaction at all.

Should I standardize on one strategy across all targets, or branch per DBMS? How can I verify at runtime that a given DDL statement really executed inside my explicit transaction rather than auto-committing? Are there practical limits (e.g., schema locks on Firebird) that argue against long DDL transactions?