If I understand it correctly what you are asking about is what Episerver refers to as TemplateDescriptors.

They don't really support having different actions for rendering the same content in different ways but they do support different controllers.

It is quite an advanced concept but i would suggest you start reading here: https://world.episerver.com/documentation/developer-guides/CMS/rendering/selecting-templates/

Thanks for the response Erik.

Unfortunately, I'm not finding a way to use the TemplateDescriptor to decorate the second controller and choose that template when rendering content under the partial router described above. I am mainly only seeing ways of tagging content partials for rendering content area items. Was there a way you had in mind of selecting the template that should be used based on the partial node it used to route the request?

I have never implemented something like this myself, we normally don't recommend having seperate URLs for "support". Often we point out the advantages of support personnel getting exactly the same view as the customer through impersonation or we control the extra support features through groups to limit its availability based on user.

Back to the question, my first thought would be if there isn't a way to add a tag to the routedata inside the partial router to achieve the same template selection.

Alternatively i was thinking of attempting to use display channels: https://world.episerver.com/documentation/developer-guides/CMS/rendering/display-channels/

Ah, okay. I understand your concern about support/customer view, in this case let's pretend the support center provided a completely different template showing post-purchase targeted content (aka Firmware Updates for a Router you bought, or User Manuals). In this case, since both are visitor-targeted just displaying different template/sections of content based on the URL you visit (even though it's a single Product entry), the suggestion based on personalization may not work.

I've moved to use Display Channels until I can find a better resolution. For anyone with a similar request, this is what I've used for now.

Inside my overridden Hierarchical Router shown above:

if (contentRecursive != null)
{
      segmentContext.RoutedContentLink = contentRecursive.ContentLink;

      this._httpContextAccessor().Request.RequestContext.SetCustomRouteData(SUPPORT_CENTER_ROUTED_DATA_TOKEN_KEY, true);
}

My display channel:

public class SupportCenterDisplayChannel : DisplayChannel
{
	public const string RenderingTag = "Support Center";

	public override bool IsActive(HttpContextBase context)
	{
		var requestParamValue = context.Request.RequestContext.GetCustomRouteData<bool>(SupportCenterCatalogNodeRouter.SUPPORT_CENTER_ROUTED_DATA_TOKEN_KEY);

		return requestParamValue;
	}

	public override string ChannelName
	{
		get { return RenderingTag; }
	}
}

The downside of this approach is that "Support Center" is a display channel across the entire site, as display channels are normally reserved for rendering differently based on a target device/environment like "Mobile" or for whitelabeling. The commerce content is the only part of the site that has a renderer setup for the "Support Center" display channel, making the display channel a little odd to be shown in the Editor Interface for all content.

I don't think Display Channels was the correct way to accomplish the task, but for now this works and makes for an easy way to not only give us separate templates per routed path, but also an editor-previewable display channel to see products as they would appear in the Support Center.

I believe CMS solves for this using RouteTable's extension for "MapContentRoute()" which would allow me to do something similar to:

RouteTable.Routes.MapContentRoute(
        name: "SupportCenterCMSRoute",
        url: "{language}/support/{node}",
        defaults: new { action = "Support" },
        parameters: routingParameters);

Which would give all CMS content an optional prefix of /support/<normal_url_path> and automatically route that content to the default action 'Support'.

Unfortunately that doesn't exist for Commerce. I'd love to see it though.

Thanks for the help!