The rewritten package is the contrib/portal package. Open Force started on this project a year ago summer, when they dropped out it lay untouched until last summer. I worked on it for a couple of weeks last summer but got busy with other stuff, but got back to it a week or two before going to Guatemala (University of Galileo) for most of February.
At the moment it does not work with .LRN. Also its caching is probably less effective than new-portal at the moment since I didn't address this problem while reorganizing and rewriting big chunks of it (mostly because, if folks approve my TIP, I'd prefer to use the caching db_* API rather than util_memoize to do the caching).
Mostly I find OF's use of ns_sets for passing stuff around annoying but beyond that haven't looked into what it would take to make specific portlets cache their content. As I said above they really need to coordinate with caching versions of the underlying application if we're going to provide the user consistent views of application content. That's not a short-term fix, obviously, and short-term we may need to kludge things optionally ...
Of course one can ease the pain by minimizing the number of portlets per portal page. Ideal would be one, then you'd have the equivalent of application pages rather than portalled pages! :) OK, I'm being silly, but perhaps this helps make clear that when it comes to content it is really the application's responsibility if we're to present consistent views of content? Portal pages are bad performance-wise because rendering one's the equivalent of rendering index pages for several non-caching applications all at once.
