If you want the training wheels without the bike, you can start with the lowest common denominator, but that will compell nobody to switch from their templating system to your backend system.

For most people, their templating system "just works", and depending on the application, one templating system is more suited than the other. But you don't gain much benefit of making the templating frontend interchangeable, as people usually don't switch templates, and even if switching templates, any such switch will involve changes in the driving software anyway.

The only thing that could possibly be saved would be that one doesn't have to install yet-another-templating-package just to support the new templating syntax, but if an application switches its templating system, that's a minor point anyway.

DBI is different, because it makes the backend exchangeable for an unchanged frontend. Your abstract templating idea tries to make the frontend and input data exchangeable, but changing the frontend and structure of the input data is not something you do on a whim or have as difference between development and produciton environment.

You can compare an SQL statement to a template, and the DBD is the templating engine. But with DBI, you feed it always the same statement, only the transformation for the backend differs. With your solution, you feed it different input to create the same output - this sounds more like different programs than something that should be solved by plugins.