In regards to the rendering problem ... my 1st solution -- don't change user-input characters into HTML entities, wouldn't affect the ability to say 'amp' after a ampersand. Only if we went with the 2nd option of preserving roundtrip integrity. I preferred the 1st which had it not changing the user input, so it wouldn't need to change it the 2nd time, which caused the problem you mentioned.

I used a literal pi, which was changed into the #960 form in the edit buffer, but then didn't change it back on display. FWIW, all of the different renderings of pi you tried display as pi on my system. Maybe it's a matter of browser configuration? I have my browser's fallback character encoding for 'legacy content'sic that fails to specify a character encoding to UTF-8. It rarely fails -- indicating that even new pages that fail to specify content are usually UTF-8. I'd say <10% actually use western as a default...