Note this is present whether you are placing multiple copies of the same form, or just two completely different forms that happen to collect some of the same data (for example, "First Name") on a web page.
If you try directly walking from a label to its associated input field, it'll fail. For example, let's say the label is in javascript variable 'fieldLabel' and so this javascript:
fieldLabel.control
is supposed to take you to the control indicated in the label's "for" attribute (useful if you want to tweak a form field based on characteristics of its label). Unfortunately, Marketo gives multiple instances of the same field name the same Name/ID while the browser is expecting ID's to be unique, so that method will retrieve the correct input field only accidentally. It will always return the first matching input field, even if the label you started from is inside a completely different form on the page.
Just wanted to save someone else time tearing their hair out over why their javascript wasn't working. Took me a while to realize the first form's fields were the ones changing in reaction to the characterstics in the second form's labels.
Went a slightly different direction, myself. I just stopped trying to walk directly from label to field. For completeness' sake I should probably go back and change the field ID's, but since this was the only time the duplicate ID's bit me, for the quick-and-dirty fix I put in a scoped a request to the children of the form when looking for the field ("#formID #htmlFor" as a query selector string) rather than using the .control field. It's a query selector tht borders on the absurd, but the underlying spec is robust enough to handle uses that lie outside the original intent of the tool.
And yes, i love Marketo's response to your ticket.
I put in a scoped a request to the children of the form when looking for the field ("#formID #htmlFor" as a query selector string)
That's the same as formEl.querySelector('[id="'+ labelEl.htmlFor + '"]').
Yep. But you used it to change the field ID. As I noted, instead of changing the ID and the label's htmlFor (which would have the effect of making the fieldLabel.control attribute I mentioned work properly for the rest of what I was doing) I took a slightly different approach and used that query instead of fieldLabel.control to directly modify the field attributes with javascript (copy the label text into a placeholder attribute for the associated field and set the required attribute, if you're curious). I didn't need the ID changed to do that, but I'll probably get around to adding that in a future version, just for completeness' sake.
Feels sometimes like I'm more than halfway towards building a DIY templating system that takes a Marketo form as input, strips it down to bare fields and labels, and writes out a brand new form. I may yet end up there, but I'm hoping not.