Bug in Email templates with similar Standard and Custom field names

I've been working on several workflow and email alerts lately.  I recently came across a curious defect with email templates.  Honestly, I don't know if it's strictly limited to the templates.  The defect involves an object which has standard and custom fields with the same 'name'.

If the object has a Standard field name and a custom field Name__c, an email template will pick up the custom field.

Steps to recreate:
1) Go to Setup->Create and Create a custom object 'obj' with a custom field of Name.
2) Go to Setup->Create and Create a tab to the custom object.
3) Go to the custom object tab and populate the object with Name='AAA', Name__c='BBB'.
4) Go to Setup->Communication Templates and create a test email template with:
  Subject: Name should be AAA {!obj__c.Name}
  Body: Name 1 should be AAA: {!obj__c.Name}
  Name 2 should be BBB: {!obj__c.Name__c}

5) Save the email template.
6) On the template, click 'Send test and verify merge results'
7) Populate the template with a valid contact and your new obj__c object.
8) You will see the defect.  The subject will say: Name should be AAA: BBB

Leads, Campaigns, and Workflow

I have a requirement for a client that wishes to create a Web 2 Lead form and assign it to a campaign.
Once that is done, a workflow shall fire off a series of emails depending on what sort of campaign the lead is tied to.  This sounds easy enough to do with Salesforce's out of the box Web2Lead functionality and workflow, but there were some other tweaks we needed, so utilizing our own solution is the only way to go.

- The form -
Utilizing a jQuery modal, the user clicks a link and populates a small web to lead form.  When the user hits submit, sever side validation happens in a VF controller, so we can control the UI (messages and labels if a field is required for instance). 

- Allowing Portal users to use the web 2 lead form -
Once the form is submitted, it stores the lead in a custom lead object.  The custom lead object is needed, since leads cannot be created (owned) by Portal users.  When a portal user creates the mirrored lead object, it fires off a trigger calling an @future method to insert the lead and campaign member.

- Tricky workflows with Leads and Campaigns -
Here's the tricky part of the workflow.  When the lead is inserted, it doesn't have access to its related Campaign member and hence related Campaign (the Campaign member is a junction object to connect Campaigns to leads or contacts).  Our workflow needed to look at the Campaign Name field on the Campaign.  The lead doesn't have this when it is inserted, nor if the Campaign member is updated, does it update the lead.  Therefore, modifying the campaign member or campaign doesn't fire the workflow rule until the lead is updated next.  This is true even if the workflow rule is set to 'Created or did not previously meet the criteria'.

The solution is to create the workflow rule on the Campaign member and not the Lead.  When the Campaign Member junction is created, it should have access to both its Campaign and its Lead objects.  Thus, when the member is created, we can create a rule like 'Campaign Name equals My Name' and fire off a workflow when the Lead is assigned to the particular campaign.

Hope this helps others.