Geek question - Why is there no render array for links in D7?

I don't think you were being harsh, just kidding around. ;)

Would there be value in me trying to write a patch to menu module to get some renderable arrays in place? I'm guessing that it won't likely get accepted, but what the heck, if it doesn't break anything. It's all display side afterall.

If I were to create a renderable array for Menu module, what "types" should be defined? I can think of two off-hand - one that generates basically the same output as menu_tree_output(), and another that replicates menu_navigation_links().

Obviously these aren't critical isssues to solve for D7. I'm mainly interested as an exercise in understanding hook_element_info() and the guts of renderable arrays.

One of the current limitations of drupal_render() is that all you have is hook_element_info_alter(), which means you can only alter the definition of an element type, and therefore only add #pre_render callbacks (or whatever other callbacks) for elements that have a #type. And you'll find a bunch of render arrays throughout D7 don't have a #type, only a #theme, as in the case of what menu_tree_output() returns. This pretty much sucks, and IMO, is worth fixing in D8. If you want to start submitting patches to D8 that set a #type on more render arrays, that would be awesome. I doubt those patches would qualify for backporting to D7, but who knows.

I don't know if your above example code intended to imply this, but another approach would be to add a hook_element_alter() for drupal_render() to invoke on the element itself, as a complement to hook_element_info_alter(), which acts on type definitions only. I think this would be pretty sweet, but I think it might add too much performance slow down to be accepted.

In general, what we're able to do on render arrays, is still pretty primitive, compared to, say, what jQuery can do on a DOM. http://developmentseed.org/blog/2009/mar/01/limitations-drupal-theme-layer contains some great ideas for improvement, and I'd love to see some of them implemented in D8, but again, we're constrained by PHP's function call overhead. Maybe something clever can be figured out though, it'll just take a lot of experimentation, which means people with enough time on their hands to delve into attempting some different approaches.

Keep in mind though, that a lot can be achieved via the theme system and preprocess functions. If you find yourself stuck at the render layer, you can maybe get unstuck at the theme system layer. One of the things that's happened in D7 is that there's now often many ways to achieve the same goal. There's a bazillion alter hooks. There's #pre_render. And there's theme preprocess functions. I think we'll all be learning a lot in the next year on when to use what, and hopefully applying that knowledge towards simplifying it all for D8. And like mikey_p says above, there's a lot of improvements you can try via writing a D7 contrib module. Attempting that is a great way to learn, and putting it out there is a great way to collect feedback from a variety of use-cases. It also means people get to benefit from it now, and not wait for a D8 release, and it helps the chances of the improvement making it into D8 core, since it's been "battle tested".