Profile standalone form has no key, creating a race condition between different users

The CiviCRM Profile Controller is configured with ignoreKey=true. This means that there is a single global entry in the cache called "CiviCRM_CRM_Profile_Form_Edit_" for all profile forms being edited.

Our experience with this bug shows how serious it is:
Before we knew about this bug, we sent out an e-mail to all our members using profile (with links in the e-mail containing checksums so they can fill in the profile form), asking them to volunteer for activities, with read-only fields for contact names. Large numbers of members replied completed the form, and our administrative staff started noticing that some contacts had suddenly changed their real name in our database (which is supposed to be something that only staff can do).

After investigation, we found out that each change had this sequence of events:
Member A clicks on the URL to authenticate by checksum and load the profile form. The form includes hidden inputs containing the first and last name of member A; the ID is saved in civicrm_cache with path='CiviCRM_CRM_Profile_Form_Edit_'
Member B clicks on the URL to authenticate by checksum and load the profile form. The form includes hidden inputs containing the first and last name of member B. The ID is saved in civicrm_cache with path='CiviCRM_CRM_Profile_Form_Edit_', overwriting the previous entry.
Member A clicks save. CiviCRM fetches the form, including the contact ID (for member B), and saves member A's data against contact B's ID.
Member B's name is now set based on the hidden values on Member A's form.

Setting aside the fact that Member A could have edited their hidden attributes to change supposedly readonly values (that is a different bug), this means that profiles are unreliable and essentially useless on any system where there could be more than one concurrent user.

Issue appears to still be present in trunk SVN; patch against trunk submitted.