The overall concept of templates (at least those used to render screens and screen controls) is to have them closely match the heirarchical structure of the Screen and ScreenControl objects in the code. That is, one or more top-level templates are used to render the Screen objects, which then in turn delegate (using the VTL #parse(<template name>) directive) to render the controls on that screen. In much the same way that controls aggregate other controls (for example, the QuestionControl object has a LabelControl and InputControl attached to it), these control templates can delegate to other control templates depending on what type of control is being rendered. Hence, the naming scheme for the control templates is obvious: the control represented by the SomeControl object in the code is rendered using the SomeControl.vm template.
It is the responsibility of higher-level templates to determine which bottom-level template to delegate to (that is, the one that actually outputs the HTML) to render a particular control. Hence, multiple bottom-level templates can be provided to render the controls - one for each different way a control can be shown. Or, alternatively, this logic can be contained all within one bottom-level control. Hence, for example, if we sometimes wanted to render a boolean input control as a drop-down combo box and sometimes as a set of radio buttons, we could have two templates named BooleanInputControl_DropDown.vm and BooleanInputControl_Radio.vm. Or, just as well, have only one template called BooleanInputControl.vm which determines for itself which way the control should be rendered. This is a lot of scope for personal preference in the naming and structuring of the templates - there is no (at least as of this writing) hard-and-fast rules that are enforced either in the application or the template logic governing this. This, however, may change. The only thing to keep in mind is that if the logic in one template is changed, the logic in all templates that it interacts with (either in its own heirarchy or related templates) is suspect. It is recommended that changes to naming schema, heirarchy, logic etc. in the templates is either done wholesale or not at all.