The "::checked" pseudo-class selector is supposed to assign a rule based on the "checked" status of a checkbox or radio button. But WebKit only checks the initial attribute in the HTML, and does seem to pay attention to changes that the user makes. The pseudo-class is clearly supposed to reflect whatever the current state is, not just the attribute value at load time. But it doesn't. In the example, you can see the check-mark change on the box when you click on it or click on the label, but the styling does not change in response. Compare this to FireFox or Opera, where the checkbox actually determines the display or not of the nested UL.

Also see the radio-button equivalent on this page:
http://bradclicks.com/cssplay/tabs.html
... in which the radio buttons have been left visible in order to illustrate what is happening. Clicking on the tabs (actually labels for the radio buttons) should change the display, as it changes the checked status of the radio button.

It seems that some progress has been made on this. Now the immediate sibling registers the changes to the "checked" status, but its next sibling does not. So this rule works as the box is checked and unchecked:
li input:checked + label:after {
content: ' (click to close)';
color:red;
}
But these do not:
input + label + ul { display:none; }
input:checked + label + ul { display:block; }

Yeah this case fails "on purpose" right now, since I wanted to come up with a performant way of doing it. Ideas include:
(1) Just re-resolve everything after the first changed sibling. Could result in bad slowness in pages as a result, but then again, people chaining these selectors are kind of asking for it. ;)
(2) Waste more memory and hold a maximum sibling chain count in the RenderStyles. This count would enable you to only re-resolve as many siblings as necessary on a change. Would be faster but RenderStyles would have to grow (making all pages take up more memory).
I'm inclined to just do (1) and not worry about the performance.

Choice number 1 would be better than nothing. What are we talking, maybe an extra quarter second or less after the checkbox is clicked, in an example such as that given? I could see how it might be worse if I had an entire complex page re-render into something vastly different based on the checkbox, but in my example the display property is the biggest change.
I kind of imagined that the extra memory would only have to be set aside when there were actually sibling selectors in play, in rules that combined them with dynamically updated pseudo-classes (hover also comes to mind). Like maybe you would pre-render screen regions based on what would be needed later with such rules. But I don't really know what I'm talking about when it comes to memory allocation.