I've mentioned this a few times elsewhere, but I thought it would be clearer if this were proposed as a discrete task.

@matmarex will leave a note with next steps on this task and the rationale.

For context, the idea was mentioned at T230653. We talked about it a bit internally in engineering meetings as well.

Right now we're not planning to work on such a thing, because:

• As this would be a wikitext change, it would be very difficult to get everyone to agree on it (there are many people in the editing communities and among MediaWiki developers with very strong and conflicting opinions on changing wikitext; a particularly common opinion is that it should not be changed, but even among those who want to evolve it there are lots of different ideas about how)
• We're already considering a different wikitext change, to allow multi-line comments (or list items): T230683. We wouldn't want to overwhelm everyone by proposing several unrelated changes at the same time (and even the preliminary discussion on that task has been… fatiguing due to the multitude of ideas).
• It appears that the "parser" we wrote for DiscussionTools to detect the signatures in their existing, messy format, actually works better than we expected. It should be good enough that we don't need to plan to replace it.

(I think I'm summarizing the thoughts of most developers involved in the talk pages stuff, but I didn't consult this summary with anyone else, so any mistakes in the above are mine :) )

For the record, my proposal is to eventually solve this via the mechanism described in T230658#5916798 which would allow the signature parser function to add attributes to the wrapper around the comment content. I agree with the @matmarex summary in so far as the current hacky/messy id mechanism will work "good enough" for quite a while, so there's no strong pressure to address this issue (T246073) right now. We can get T230683: New syntax for multiline list items / talk page comments and a lot of DiscussionTools done first, then eventually circle back to this as a way to make the id mechanism more bullet-proof in corner cases (eg, perhaps to assign a more permanent id to handle the case when talk pages are archived or moved -- although here too some hacky mechanisms based on naming conventions for archived pages or a look-aside database of moves/renames will probably suffice in the short term).