Currently, EditPage has the 'EditFilterMergedContent' hook, which provides the new *text* of the edit, along with other data such as the summary. While that's OK for some consumers, others may need the *PSTed* text of the page. Right now I'm thinking of AbuseFilter (some variables will return the links contained in the new text), and especially SpamBlacklist. SB will effectively PST all edits, because it always needs the added links to filter them.
Fortunately, we have a Parser cache and the new text of the edit will only be parsed once. However, I don't think that we should rely on this in the long term. It's also a little confusing, if you look e.g. at the performance flame graphs (it could seem that SpamBlacklist is very time-consuming).
Hence, I propose that EditPage[1] should run a hook after having PSTed the text, passing the result in. This would deny the need to run PST in extensions when needed. Also, such a hook should be executed only if the page is going to be saved (i.e., not if the PSTed content is the same as before), so that extensions don't have to check for that.
The EditFilterMergedContent hook should remain in place, for consumers that do not need the PSTed text.
[1] - Or a related class, as long as it's guaranteed that the hook will only ever be called on page edits.