Yeah, I think this argues for making much more focused hints. Just note P tags and CODE tags (and that < and [ might need CODE tags), quite concisely, with examples, directly above the Title box (with a ^?-style link to more detailed help). (Maybe also discourage BR tags; we hates them fat, stupid, nasty habitses.)

As for more DWIM, I wouldn't do any of the many "wiki" mark-up styles nor would I do POD (at least at first). But I would like to take a couple of good ideas that are common to many of those:

1. Turn blank lines into <p> tags
2. Enclose indented blocks in <code> tags

Another DWIM feature that I'm surprised has never occurred to me before nor do I recall ever having seen it suggested: Require a space (or open paren or quote) before and not after [ for it to be transformed into a link (for users who haven't chosen "expert" mode).

I think those three "simple" DWIM features would eliminate a sizable majority of the formatting mistakes here. There is a bit of a trick in how to decide whether to apply those features to a particular node.

I think the most likely way to get this is to add a "format type" field to all write-ups and as a user setting. The choices would need to include at least "traditional PM" formatting that does no DWIM (for existing write-ups and for users who don't want any "improvements") and a "DWIM" formatting that uses the above 3 DWIM features while allowing all of the traditional PM mark-up. I'd probably just have all users default to "DWIM" formatting for their future nodes. A per-node over-ride would also be nice, especially for persistently anonymous monks.

It might be worth-while to have other formatting choices but I've talked myself out of all of the other options I've considered recently. I even considered having a UTF-8 format option, but I think it would be better to just convert the database en masse to UTF-8 (which would also tempt me to restrict the character set for node titles, but then Perl 6 would just use some such restricted obnoxious character for some strange operator and then we wouldn't be able to talk about it properly).

Oh, I just did some spelunking via SQL and my nefarious plan for /(?![^\s(>"])\[(?!\s)/ being optionally required for links to be expanded appears to indeed be a very effective heuristic. :)

I will try to get around to trolling the recent previous suggestions for how to redo the "hints" and come up with my own exact recommendation for the new to-the-point and in-your-face hints.