TL;DR: I see no reason to require that a logo reflects aspects of the project beyond the basic public interface, and absolutely no reason to make a logo design unnecessarily complex for such a reason, because there shouldn't be any pressure on users to get involved beyond the public interface, except as and when they feel the need themselves.
I've been thinking a bit more about this and I wonder what kinds of misunderstandings of the model you are thinking of. The closest thing I have seen on this list and on StackExchange has been users getting bitten by this or that feature of LaTeX or RestructuredText not being representable in the current AST format. I wouldn't call that misunderstanding of the model but rather ignorance of what structural elements of supported markup formats *the current implementation of the model* can or cannot represent. That's not even limitations of the model but limitations of the current implementation which could be removed[^1] in a future implementation. I would argue that if they were removed most users would just say "phew, finally pandoc supports my favorite markup feature" without caring about what changes in the implementation, let alone the model, have made it possible. That is as it should be. Users should not be required, prodded or even expected to understand the engineering behind an application, only the public interface. What sets open source apart is that users *may* explore, understand and get involved in the engineering, even are invited to do so, but there should be no pressure to do so. Even those who do get involved usually only do so as and when they are able and willing to enhance their own use of the product, or for their own gratification, and that's entirely as it should be. Myself I'm still a total Haskell illiterate, confining my contributions, and hence also my understanding, to filterland. I have gotten rather involved in Jakob's Perl filter support project, but that's in the end also helping myself to write filters in my preferred language. To be sure I have written some filters in response to requests on this list, but naturally that has been as and when I have had, or got, an interest in the functionality requested. Otherwise I have only more or less successfully requested John or others to add features I have needed. That may change some day but there are hundreds if not thousands of users out there who don't even get to the level where I am, and that's entirely legitimate.
[^1]: NB I'm saying "could", not "should", but I'm thinking that even without extending the current set of AST elements some unsupported input format constructs could optionally be turned into Div, Span or link elements with certain attributes by the readers so that they could be handled with filters or turned back into their original constructs by the corresponding writers -- optionally, since those attributes containers would clutter the markdown output. That's another discussion however!
/bpj