Have you read through the threads on github? This particular discussion topic has been discussed at length.... Probably once every few months I'd say at least.

I'd highly suggest reading through some of those threads as it may influence many of the design discussions in your HIP.

To clear up some things: Helm 2 had a selectable engine interface since its inception. Chart.yaml provided an optional engine​ field. The Rudder gRPC API made it possible to implement a remote template renderer. But after 5 years of development and advocating it to many community members, nobody wrote an alternative template engine. The engine interface never saw any enhancements, changes, or refactors. So we removed it in Helm 3 as the code had gone stale, and the design did not fit into the new model with Tiller/Rudder being removed.

One primary concern with prior proposals was they did not provide a solution to the "one size fits all" problem. Some proposals argued that a chart could declare the need for an alternative template engine that does not exist in mainline Helm, relying on a "plugin" model to handle template rendering. That discussion led to further debate on how plugins could be resolved, how the API contract will fit in, how the user is expected to install the right rendering engine for their chart, etc.

Discussing your ideas in a HIP would be worthwhile, but I do want you to understand that this topic has been discussed in the past. I look forward to the proposal.