While all other urgent bugs are being addressed this one seems to have no owner. I'd rather loose the twisty / rest feature than having twisties that do not work with respect to remembering state

So we either fix this or revert to static IDs

Who is taking ownership? I want 1.1.1 out within the next days because 1.1.0 is bad for our image and our users. I need a volunteer developer . It must be relatively easy to reimplement static ID if an remember is enabled.

Without but with a remember=on parameter, IDs are assigned automatically. As they are random, their previous state can't be retrieved.

As a consequence whenever remember is switched on we need a stable non-random ID.
Either it is specified explicitly by the user, or a non-random one is generated.

How do we generate a non-random ID while still preventing async'ly loaded content from reusing IDs?

If there is no (easy) answer to this question, we have to switch off random IDs and go back to enumerating them strictly, but only when remember is switched on and there's no explicit id parameter.

It follows that you will only get the remember feature in ajaxed content if you also provide an id. Non-ajaxed twisties' remember feature works fine even without an explicit id parameter. Does that make sense?

Just a silly id, but can't we generate a not-so-random-but-still-unique ID for twisties with remember ON? Something based on, I don't know, a dedicated counter for remember'ed anonymous (no ID) twisties? Would love a use-case to figure it out.

For the record, and peace on Earth, I fixed it like we agreed. I even went a bit further and appended a random (or not, if remember is set) value every time, to restore 1.0 behavior. As Arthur pointed out: theoretically you could have multiple attachment blocks for instance, so an id set in a TMPL may not be sufficiently unique