Ideally one could simply extract Drupal's form-building/client-validation to avoid reinventing the wheel. I've enjoyed using ZF1 forms on past (non-Elgg) projects and there's nothing stopping us from trying that out in Elgg. Just have to figure out...

page/elements/head has a lot of internal functionality that could potentially get important changes even within bugfix releases. We should do what we can to ensure devs don't have to override it in plugins.

To get us started: Menus are currently not generated with views and probably should be. It would be handy if more core forms had extension points inside the form and above the foot/submit button.

We all know how view overriding leads to plugin order dependencies and other problems, so how can we make views more easily customized? What views are you most likely to override in your plugins and why?  Where could we split some views up,...

It's hard to understand how this code is organized, but this token generation scheme looks very insecure. You probably want to use hash_hmac with a strong secret key.

Arrays are stored as multiple metadata rows. $cities = (array) $ent->cities; // push $ent->cities = $cities;

Currently this is not possible. We would have to allow data URLs to pass through filtering and we're not certain most site owners would want that.

Hostname redirects need to appear before page-level redirects.