In html/template, when do you need Template.Clone before adding variant definitions to a shared parsed set?

## The collision Clone exists to solve Layout inheritance in Go templates works because a page contributes a definition under a name the layout invokes — conventionally `content`. That is fine for one page. With twenty pages, every one of them defines `content`, and a template set maps each name to exactly one body. Parse them all into a single set and the last file parsed wins: every URL renders the same page, with no error anywhere. So the set has to be split. `Clone` is the standard-library answer. ## What Clone gives you `func (t *Template) Clone() (*Template, error)` returns a duplicate of `t` **including every template associated with it**. The documentation states the intent directly: clone is for preparing common templates and then using them with variant definitions added after the clone is made. The underlying parse representations are shared rather than deep-copied text, so the operation is cheap; what is duplicated is the *name space*, which is the part that must be independent. A definition added to the clone does not appear in the original, and vice versa. The idiom, therefore: 1. At startup, parse the layout files once into `base`. 2. For each page, `c := template.Must(base.Clone())`, then parse that page's file into `c`. 3. Keep the resulting per-page sets in a map and execute the layout's name out of the appropriate one. Every page now owns its own `content`, and nothing can overwrite anything. ## The html/template restriction `html/template` is not just `text/template` with an escaping pass bolted on the output side. The first time a set is executed, the package walks its parse trees and rewrites them, inserting escaping appropriate to each syntactic context — HTML text, an attribute value, a URL, a script body. That analysis is done once and recorded in the templates themselves. A clone taken after that would carry trees whose escaping decisions are already fixed, and any definition added to the clone would be inconsistent with them. Rather than produce subtly unsafe output, the package returns an error: an executed template cannot be cloned. Parsing further definitions into an executed set is refused for the same reason. The practical rule is a lifecycle rule. **Everything that changes a template set happens before anything renders.** Parse, `Funcs`, and `Clone` are initialisation-time operations; `Execute` and `ExecuteTemplate` are serving-time operations. A lazily-built cache that clones on the first request for a page is a bug waiting for its second request. ## Concurrency A parsed template may be executed from many goroutines at once; the package is explicit that execution is safe in parallel, with the obvious caveat that two goroutines writing to one `io.Writer` will interleave. What is *not* safe is mutating the set while requests execute it. That is a second, independent reason to do all construction at startup and treat the sets as read-only afterwards. ## Clone and per-variant helpers The same pattern covers variants that need different helper functions rather than different markup: clone the base set and attach the variant's function map to the clone before parsing the text that calls those helpers. The clone keeps one variant's helper table from becoming everybody's. ## Error handling `Clone` returns `(*Template, error)`, and in initialisation code it is almost always wrapped in `template.Must`, which panics on a non-nil error. That is the right severity there: a service that cannot build its template sets should not start. Inside a request path, `Must` would be wrong — but by the rule above you should not be cloning inside a request path at all. ## The short answer Clone when independent variants must define the same name on top of shared material. Do it before the set has executed. Do it at startup. Then never touch the set again.