Here are few more thoughts about rendering the block without a root element:

I think it keep generated HTML lean and semantic. A custom root element or div is not necessary to display the content, so in the name of terse, clean HTML, it should be avoided.

It will also provide a generic solution so other kinds of characters can be represented by sets of markup. An attachment is represented by an object replacement character. If you want to represent a page break, you can represent it with a form feed character. The page break can be used to mark where to do pagination on render and might be represented by a styled hr.

What is the best way to remove the root element? Does not having a root element affect selection and the cursor?

Instead of changing the behavior of attachment pieces, it might be easier and more desirable to allow configuring the html structure used to render attachments. That way people who switch from the default <div> block element to <p> (or any element that only permits phrasing content) can customize the attachment template to use non-block elements if they choose.

If an attachment is rendered in a phrase-content-only default block (<p>) as phrase content, I think we lose the ability to provide captions, and the supporting elements like remove buttons. Or we have to do something hacky to put them outside the <p>.

If people are allowed to choose the template, I think we should do it in a template engine agnostic way so people can use their favourite engine. A Trix.Operation seems like a good candidate.

I think it might even be worth allowing people to set the renderer for each block type. Then if an attachment is isolated to it's own block and the correct block attribute applied, Trix will know how to render it.

@jeffreyguenther why was this closed?

It's been a long time since I did this work, but I believe it's because the work was out of scope of what the maintainers wanted/I didn't have the capacity to develop it further. My memory is a little fuzzy.