I have personally only worked with the backwards-compatible databases approach. The main benefit is that it well understood and works for a wide variety of deployment types, including canary and blue-green; I have used that approach even without the benefit of a blue-green deployment strategy (the mundane rolling deployment to all servers, which is essentially a fast canary deployment). Having to deploy database changes before application releases is common to several deployment strategies not that burdensome compared to the need for complicated triggering or mirroring mechanisms between different database versions.

Your third scenario also falls into the trap of needing triggering or mirroring between the database slices as well. In RDBMS terms, this is typically unsupported or completely impossible because there is only master database and all other instances do not accept write operations. The net effect of this is that the version of the master instance is the de-facto version of the whole database.

Certain No-SQL databases do not fall into this trap. For instance, MongoDB will happily allow multiple, different versions of document schemas in the same collection. This allows your application to be informed of the data version and handle the documents differently. However, MongoDB is not appropriate for all applications (just like an RDBS is not the right data store for certain types of data).