> How about just making a sensibly-behaving __iter__ for ElementTree?

Well, the problem is to determine what "sensibly-behaving" is. I can see
three options.

1) tree.iter()  ==  tree.getroot().iter()

2) iter(tree.getroot())

3) iter([tree.getroot()])

The second option feels plain wrong to me.

The last one would allow the extension towards PI/comment siblings, as I
described before. There isn't currently a way to get at them (which doesn't
hurt, because ET doesn't currently even pass them through from its parser,
as discussed in issue 9521). Once there is a way in ET to parse them in (as
in lxml), making ElementTree objects iterable would nicely solve the issue
of how to process them afterwards.

It's not the only solution for that problem, though, adding a
".gettoplevel()" method would similarly work. Thus, either 1) or 3) would
fit the API, with the downside of 1) being that it's just completely
redundant functionality and I don't consider saving 7 simple characters
worth the increase in API overhead.

That leaves 3) as an option. It's nice because the iteration then works on
the same axis as for Elements, so x.iter() and iter(x) would behave in the
same way for both classes.