mavoweb
Non mv-list-item children (<tr>s) get replicated when the mv-list is a <table>
Yeah, this is because the proper table structure assumes a <tbody>, and if you don't add that, the browser does. So by the time Mavo sees the structure of your HTML, it sees:
<div mv-app="appName" mv-mode="edit">
Static trs are being replicated, as well as the "add item" buttons!
<table mv-list="stuff" mv-initial-items="2">
<tbody>
<tr>
<td>First</td>
<td>Second</td>
</tr>
<tr mv-list-item>
<td property="first"></td>
<td property="second"></td>
</tr>
<tr>
<td>First Footer</td>
<td>Second Footer</td>
</tr>
</tbody>
</table>
</div>
So it assumes the <tbody> is the item of the stuff list, and then you have an orphan mv-list-item. It tries to turn the latter into a list as well, by wrapping it with another <tbody>.
I'm tending to mark this as WONTFIX since there's no way to fix it — the original HTML structure cannot be recovered.
But, the original mv-list-item is still present, now as a grandchild of the mv-list. So why not have mavo replicate the grandchild?
I would say any uninterrupted descendant---if there's an intervening mv-list then of course that should take precedence. Put another way mv-list-item should tie to the closest mv-list ancestor.
If creating lists with just mv-list or just mv-list-item becomes commonplace (rather than just error recovery), I don't think we can assume that was the author's intent.