Maybe I’m not familiar enough with your problem but I don’t see the value that you add by allowing Mendix to find a template by enumeration value as to specifying a string value to retrieve a specific template. Maybe you gain a bit in terms of governance but you really should only have developers/semi-technical resources touching this side of the app that are aware of the repercussions of changing a Template Retrieve’s query parameters.
If anything, I would create Sub Microflows named after the email functionality (ie. SUB_Registration_SendEmail) that perform the necessary template retrieve and send the queued email (First two actions in your screenshot). This creates a single piece of reusable logic so that whenever you need, you can place it within a trigger’s Microflow or Nanoflow to perform the logic in a standardized fashion. This approach also allows you to expand in the future by adding input parameters which will help standardize the information you might need to send that email if you find that you need specific information to replace as tokens in said email.
With that being said. If this functionality is actually required by the business. A common practice amongst more enterprise clients is to duplicate the module. This allows you to modify and maintain the module without fear of it being overwritten by updating the original module. Looking to the future – If something breaks in the module due to a new release. The Email Module with Templates is published and maintained by Mendix to work with each release. Although sometimes pretty technical, you can poach the updated functionality and bring it into your company’s module and make the fix. (New branch for that kind of work would be a good idea)
I can’t say I necessarily recommend this approach unless it truly is required by your Organization/client. Although you may get the functionality you feel you desire. It also increases operational overhead for the application and your development team as the module grows.