Dear Emma,
The cookie-management code of mktree is not very efficient and has no simple interaction semantics with the CSS classes liOpen and LiClosed (controlled via backend). If OpenACS would set for every inner node of the tree a cookie, it would set example for the page openacs.org/xowiki about 40 cookies. The approach of mktree does not scale well, when e.g. a user is in many communities with many pages using mktree. We use a similar change in learn since a few years, and some users carry quite an impressive list of cookies for mktree with them. Once the users are used to the feature, one has to continue to support it, which makes the usage of nicer tree interfaces more effort.
The code based on IDs has some more problems, like e.g. the ID management (how to keep the IDs unique per page), esp. when pages content are included. In the case if the coockie management of mktree it is even worse, since if the same ID is used on *different* pages, the list item will open on a page B magically, when an other list item with the same ID was opened before on a different page A. This can be avoided by a clever ID construction, but i am not sure, we want to go that far now.
I am not aware of any application in openacs/dotlrn, that uses the "remember" attribute, so i am not sure whether your comment about validation concerns the dotlrn package and openacs in general or some tailored package.
My recommendation would be to either avoid the feature for the packages of the generic openacs/dotlrn release, or to make it conditional, controlled by the package programmer (as it is now) but to use instead of the non-standard attribute "remember" an additional CSS class (e.g. "cookie") to flag that the ID of this list item should be remembered.
