(I would have filed this as a bug report in mbutterick/pollen: book-publishing system - pollen - Gitea: Git with a cup of tea, but there’s no sign up button).
Consider the following evaluation:
> (decode-paragraphs '((div "First block") (@ (div "Second block") (div "Third block"))))
'((div "First block") (p (@ (div "Second block") (div "Third block"))))
The addition of p is invalid.
Maybe try manually adding @ as a block tag in the setup submodule of your pollen.rkt?
If that works, maybe the fix in Pollen is to include splicing-tag from pollen/private/constants by default in block-tags in setup.rkt. Or to always include it via block-txexpr? in pollen/decode.
Currently decode-paragraphs doesn’t do any splicing, and we probably want to keep it that way.
I tend to agree with @joel. If the @ were automatically spliced by default, it would violate the Principles of Least Astonishment and Generality. For instance, there would be no way to put two div elements inside a p. What’s the counterargument, @sorawee? Seems like it would be easy to splice the @ elements within your own code before passing them to decode-paragraphs.
I sent two email replies, not realizing the mailing list mode was not activated on this Discourse 
Adding @ as a block tag is not the same though. If I have (@ (span "abc") (span "def")), I definitely want a paragraph wrapping there.
I agree that “magic behavior” is mostly harmful. But I am not asking for magic behavior. @ promise that it will splice, so it should honor that promise (when interacting with other features). It’s a leaky abstraction otherwise.
It never makes sense to have a div inside a p. This is not a personal preference. It creates an invalid HTML, and the browsers will arbitrarily move the div out.
One argument that I can see for not making the change is to avoid backward incompatibility (though I fail to see how anyone would rely on @ not getting spliced). But in that case, I hope the behavior should be highlighted in the documentation, with the workaround mentioned.
I have now activated mailing-list mode. I wasn’t aware that it was deactivated by default.
This still doesn’t persuade me that this behavior counts as a bug, because the timing of the splicing should be consistent and predictable. As for your recommendation—should the @ be evaluated everywhere, or only in places where it would result in a spurious p tag? (That strikes me as even weirder and more magical.)
Pollen is not the HTML police. Furthermore, though the optional paragraph-wrapper argument defaults to p, it could be div, which would make your proposed behavior wrong, because a div can contain other divs.
The splicing of @ is handled by the splice function in pollen/private/splice. If you invoked that function on your txexpr before you pass it to decode-paragraphs, would that suffice?
Another idea: could decode-paragraphs simply ignore the splicing tag for purposes of decoding? (edit: in other words, act as though the elements have been spliced without actually splicing them)
