Menuitem's content model

To the attention of interested parties.
In several occasions I tried to figure out what was wrong with <menuitem>
element and its structure, but it seems that I was unlucky until now, as it
happened with my previous message here in this list. Now I try again.
Since its creation, the <menuitem> element has been in the category of
"void" elements, i.e. elements which do not have content and, as such, only
consist of a starting tag in the markup.
This is strange. <menuitem> is a brand new element in the spec. Only old
versions of Internet Explorer treat ALL unknown tags as void, but as
everybody knows this can be easily worked around with javascript
document.createElement('newelement'). The other user agents, which are
quite used to the awful habit of certain authors not to close most of the
elements they open, treat unknown elements as normal elements whose end tag
has been omitted and close them in a way they consider proper.
In this context, this means that a markup such as
 <menu><menuitem><menuitem><menuitem></menu>
which is correct according to the specs (apart from the attribute
omission), ends up being interpreted as it were written like this (tags in
brackets are those UAs consider omitted)
 <menu><menuitem><menuitem><menuitem>(</menuitem>)(</menuitem>)(</menuitem>)</menu>
effectively producing a dom which can be represented like this:
 menu
  +menuitem
    +menuitem
      +menuitem
This is clearly incorrect. Now, I know that both the specification and the
validator (who deserves an argument apart, see below) flag the use of
<menu> element with a "warning", advising the authors to wait future wider
implementations. But it wouldn't be strange for programmers to produce a
polyfill enabling the function of this element already now, so that authors
can start using the context menu and the toolbar at last! I would also add
that without examples in the wild, no tests will be really possible about
this element's viability. And even without this case, the problem will show
again in the future, reversed, in the form of backward compatibility.
I also notice that, having the menuitem finally promoted in its natural
category of normal elements as it should be, it could also have a "content
model", limited to "text". The <option> element teaches us that what can be
done via a "label" attribute can be achieved even better by the proper
textContent of the element itself. Of course the argument above, regarding
the re-insertion of menuitem in the group of normal elements, remains valid
even with "content model: empty". It's just a matter of fixing two errors
with one choice, because both having it void and empty seem unreasonable to
me.
One final note: the Validator parsing engine makes the same mistake that
browsers do, flagging the (now) "correct" use of <menuitem> as an error:
"Unclosed element menuitem". Nobody seemed interested in it, even if I
filed the bug twice.
Awaiting further discussion.