Just a note withdrawing PR 1270 - some notes are in the PR discussion itself.
1) Hook to change App::$page just prior to page display -- after consideration, I'm not sure at all what this adds. At any rate, whatever the reasoning I had for submitting it originally no longer obtains. If someone else thinks it's a good idea, I guess it could be resubmitted.
2) Hook into Articles - It looks like the better solution is for any addon dev who wants to make changes to the articles module is to clone the articles module and just make the changes. The call to status_editor() adds data to App::$page['htmlhead'], and could mess up settings if the jot editor is going to be used. To fix that would require a second hook to change the behavior of status_editor(). And by that point, any dev would be recreating significant portions of the current module anyway and may as well just go that route. It's not that big/scary or complicated. So either an addon on it's own endpoint - or even using the facility for Zotlabs/SiteModules/Articles.php (see Zotlabs/Web/Router.php) is probably the correct solution.
3) HTMLPurifier - It was a first stab to lessen restrictions in certain cases for articles, web pages, wiki entries, maybe cards while still allowing the use of nomadic identity and automatic cloning of those items. Digging more deeply, it's clear that the the way things are transmitted (see include/zot.php::process_delivery()) means that any modificatons to HTMLPurify configuration would need to be universal (all item types) and site-wide (actually ALSO be implemented on all sites where channel clones reside) in order to work. So now I see the overall concern with changing it as proposed - to work, it would not only have loosened restrictions for the desired item types on the local machine, it would have needed to be a univeral loosening of restrictions. In that way, I agree. Bad idea.
I have an different approach/alternative that I'd like to float - but I want to sleep on it and see if any gotcha's come to the fore in the morning.
Anyway - thanks @Mike Macgirvin and @Mario Vavti for your patience... you have a much better handle on the code base than I do. I trust you both enough to know that when you give resistance to an idea, there are reasons - even if they aren't readily apparent. I imagine sometimes for you there isn't more than an initial "gut feeling" that it's a bad idea - but it would take you quite a bit of digging back through to figure out exactly why - which isn't a reasonable expectation for others to impose on you. At any rate, I wanted to put these notes here - mostly for explanation, posterity, and as an apology if I came off a bit pushy.