I suspect this was an unexpected scenario. Whilst incremental formalisation means any note may be made into a prototype, I suspect this combination of prototype-and-template wasn’t envisaged. I’d note that for the first part of Tinderbox’s life templates were external files (and thus couldn’t be templates) and this may still affect some internal logic: of course, now templates are only notes in the current document. Mark B is travelling at present but I’m sure can provide a more authoritative answer in due course.
Meanwhile, if using the built-in HTML template prototype, templates really only differ in their $Text. A prototype’s $Text is only inherited once - at prototype assignment. Furthermore, if a (new) prototype is assigned after the template’s $Text has been edited the that attribute is no longer inherited as it already has a local value.
I’d propose that it makes good sense not to plan to make template prototypes as well. If you need several different prototype-based template setting (e.g. HTML vs Markdown ones), I’d suggest having multiple prototypes, one for each use case and then making templates use the appropriate prototype. If those prototypes have $Text you want inherited, then you may wish to removes the
/Templates container’s OnAdd so you can choose the appropriate prototype rather than have the action auto-assign 'HTML Template", and thus setting $Text such that a change of prototype won’t insert new default $Text (as might be desired).
If I’ve misunderstood the underlying problem, please ask, as I’m interested to understand why one might need a template/prototype as opposed to making one simply because it seemed sensible and possible to do (i.e. no one said “don’t”!).