Ah I think this might be where my original thinking came from - last time I saw this same result with a client they were doing exactly this. D'oh!
Grace - Yes, your response was what caused me to ask the question. The solution you're proposing should work though. Honestly for years all of us have been giving the advice that if you want to use the same form for entering multiple people (like on an ipad at a trade show or something) you tell people to take munchkin off the page. But this behavious I've only ever seen with using the same email. I've been told many time by Marketo product managers though that the cookie is checked first, THEN the email address, but my experience with using that theory in practice has been inconsistent at best.
I've been told many time by Marketo product managers though that the cookie is checked first, THEN the email address
That's disappointing, since in reality it's consistently the opposite of that!
The expected behavior is that a new lead is created. If someone said otherwise, they were probably confused about whether you were starting from an anonymous session or an already-associated session. (Also, people don't often know how legacy logic really works, bus factor and all.)
Now, the cookie could be said to be "checked first" in the sense that the server must know if an association already exists -- but that doesn't mean that a series of posts get merged into the same lead, it dictates whether the Activity Logs are merged or not.
I've seen this behavior intermittently too while testing some forms -- when there is an existing Munchkin cookie connected to a known lead present, submitting the form with a different email address appears to have no effect. No form fill activity is logged in the original person's Activity Log, nor is one logged to the second's (or indeed, no Lead is Created activity occurs if the new email address does not correspond to an existing record).
Marketo's advice was to continue to use private sessions or clear cookies before making additional submissions, which is fine for testing purposes but obviously doesn't scale very well to the different times your end-users may experience this.
Here, I'd sooner believe the form didn't submit at all, i.e. the form data never went on the wire, or that invalid values made their way into the form data.
Unless an instance's activity db is corrupted (which indeed can happen!) haven't seen a form post with valid data accepted at the HTTP level, yet no Filled Out Form anywhere in the global Activity Log. (Note also that certain invalid values will cause an otherwise successful post to be discarded before it gets logged, like invalid datetimes.)
Nick Nappo are you still listening? Lots of good input on your case, but we haven't heard back from you.