Not sure I’m entirely following your questions. Maybe this will help?
Business configuration recommended practices is to never modify PTC’s OOTB content. Thus, the general procedure for context templates is to create a context, configure it as desired, and then save (and export) it as a company specific template.
We name them to be company specific to differentiate them from OOTB templates. It doesn't matter what they are named as long as it is consistent. We do this for other items too, like OIRs. Typically we use the very basic naming pattern '<company> <template type>' (e.g. UPF Product Template).
I’ve never seen anyone use the Product Design template. It was provided by PTC as an example of what is possible. However, everyone starts with the General Product template and configures as needed.
We also go back and hide the OOTB templates once we have defined a company specific template. That keeps context creators from picking an unapproved template. If we need to start another context from the OOTB template, we can quickly unhide it, create our context, and hide the OOTB template again.
There are a few ways to make template updates. The cleanest assumes there is a test system, create a new context using the current company template. Make the desired changes to that new context, and then export it as a template. Go back to production and update the company template with the exported template.
This is a personal preference, recommended practice. When possible, I like to move all application context permissions up to the org and clear them from the templates. The only domain policy difference between the OOTB general product and library templates is one defined permission ‘Product Manager’ and ‘Library Manager’. Otherwise, each context repeats over 100 access permissions. Moving product and library permissions up to the organization domain (/Default/PDM) greatly simplifies domain policy interrogation and future changes. If dealing with projects, define those in the /Default/Project domain.
