Normally I would not create such a collection ticket, but I try to sum all the related tickets and try to sum it up, so that this can be used as single point of contact. I also consider major as not enough for this issue. there are about a dozen tickets that describe this or a similar issue + multiple threads on the forum.
It all started with a fix of fabien in r6014 for #2327
The fix was applied to generate different IDs for radiobuttons. This was achieved by supplying a fake array name, which causes a helper method to make the id:
name_value
#2833 mentions that the way value is used is incorrect as it can contain invalid characters. The ticket comments suggest even using a hash value rather then reencoding the value.
#3188 mentions that radiobuttons whose names are radio[] will also get the [] appended from r6014, which will result in the id being name_value_value
#2052, #1792 and #3009 say that actually the documentation is wrong because you should never make a radio named radio[], which actually would work, even though might not make obvious sense.
#2787 notes that the "magic" generation of IDs breaks for example label_for helper. The label_for helper is not aware that further magic is applied to generate an ID, but it would require exactly the same "magic" for all types of input fields. To solve #2787 it seems to be required that all input fields get their IDs generated in exactly the same way.
#2800 actually mentions that the hidden tag should generate the id same way as radiobutton tag
#1533 proposed a solution for the [][] replacement hacks, but doesn't seem sufficient for me.
#1761 asks for supporting '0' as value (!== null, not != null check), because otherwise value 0 will not get a id that follows the general name_value pattern.
In general it should be possible for the developer to "guess" what the ID will be. perhaps that ID should NOT depend on the value, as there might be unobstrusive JS that requires a known ID.
A note about BC: As it looks for me r6014 broke BC in sf 1.0.10 already, as the ID generation magic changed, and perhaps now is even more inconsistent. This looks like that it might be okay to implement a sound generation that might break (especially for radio button) BC, perhaps to actually restore BC
http://www.symfony-project.org/forum/index.php/t/10718/
http://www.symfony-project.com/forum/index.php?t=rview&th=6625
