Now we're getting into a topic that is more interesting. EmailTemplateSetting was indeed added long after ProductStoreEmailSetting and is an entity much better suited for general reuse. IMO the best way to use it with a ProductStore would be with a join table that would ultimately replace ProductStoreEmailSetting, something like:
Additionally one thing that I don't like about either of those existing entity definitions is the lack of Content support. You cannot at run-time alter the contents of the email templates or create new ones. Additionally the subject field doesn't really lend itself to internationalization. All of these issues could be resolved by modeling the actual contents of the email templates against the Content data model.
A join between EmailTemplateSetting and Content could enable this:
Seed data for EmailTemplateContentType:
<EmailContentTemplateType emailTemplateContentTypeId="SUBJECT" description="Subject"/>
<EmailContentTemplateType emailTemplateContentTypeId="BODY" description="Email Body"/>
<EmailContentTemplateType emailTemplateContentTypeId="ATTACHMENT_PDF" description="PDF Attachment"/>
I dream of a day when users can create new email templates in a WYSIWG editor with the ability to pick from a list of known variables that represents the freemarker data model that will be available during rendering, possibly even providing a sample freemarker data model so that they can see a live preview of the output with variables such as firstName, lastName, etc. prefilled with sample data.