The problem is that someone has to create that project as anything more than a shim in the first place. There is no reason a generic web framework should require a full-fledged compatibility effort to switch out what should be "just another library". Note that there are several incompatibilities with "true" Jinja2 at the bottom of that readme, and that support for built-in "Django tags" is necessary.

This is far less adaptable than Pyramid, which makes most internal functionality like that accessible via the request object, which can be accessed by your template language's typical variable evaluation syntax, and which can use Mako or the default Chameleon with just a one-line configuration change, or Jinja2 and others by installing a simple shim layer that is mostly boilerplate.

Personally, I've tried to use mako with django and found it unwieldy to pass the correct information across the controller-template barrier. This was some time in the past, however, so perhaps either the adapter or documentation has improved and the problem no longer exists. The real issue, however, is that a generic web framework would make it difficult to replace unrelated user-facing libraries in the first place.

Given the callback nature of the Django templating library with template tags, includes, and other goodies, it is not as simple as "call foo_template() and return string". As soon as a template tag is involved, internal data structure needs to be exposed, with makes * everything* much harder.

there is also https://github.com/jbalogh/jingo

Jingo serves purely as a minimalistic bridge between Django and Jinja2. Coffin attempts to reduce the differences between Jinja2 templates and Django's native templates.