I know this is not directly answering the question but is very related. I will provide a more detailed suggestion later but now I have to run. However, I strongly believe, regardless of the features you add, avoid the output of HTML from the core. That only leads to issues, complexity, and worse, such as HTML parsing :'(
HTML should be handled in the theme talking in an API-like way with the core. I'd like to see that in Q2A 2.0 but the more HTML is output from the core now the more HTML will be removed in the future.
Another related architectural change (this one could be aimed at 1.7) is being able to do so in a plugin. I mean, writing an API-layer that talks with a Frontend-layer. That way, the API-layer will modify the qa_content data and send it to the the frontend-Layer, allowing for extremely further plugin customisation and even allow 3rd parties to provide different look and feel for plugins :)
Hopefully, you know what I mean... gotta run now.
More detail
1. Regarding an API-Like core, it can be better explained with an example. See this comment. As you can see, the core is returning HTML which is not allowing easy and appropriate customization of how to respond to that change. Removing that voting delay is, IMO, a great improvement. Also think that (I haven't looked at that part of the code but I guess this should apply) if the core returns HTML then the core is telling the theme HOW things should look like, while, the theme is the one it should be in charge of that. Any piece of HTML returned by the core is actually an example of this situation.
2. Regarding the second part, the one about the plugins, it aims at applying a similar logic to the one above to the plugins. When you write a plugin that uses a module (I'm thinking particularly on a layer, actually), you code your plugin logic, as well as your front end logic, inside the same function. Now, if I wanted to change how the output of the plugin looks like (not just CSS, think even about HTML) then I should have to rewrite the layer that the plugin logic inside in order to make frontend changes. If I had a 2-level processing here I could first apply plugin logic into the qa_content array and then consume whatever I have added or changed there from the second step layer which would only be in charge of generating frontend from the previous input.
Having this 2-level layers would allow users to write their own look and feels on the plugins (not only CSS but also HTML) so that plugins have a close look and feel to the users websites. This would be a similar feature as a theme but applied to a plugin. But why doesn't the current layers allow this? It is just a matter of order. API-Layers need to be executed before Frontend-Layers and it is not possible to control this order right now. I can't think of an appropriate fix for this situation... the most flexible, and probably easiest one, would be adding something similar to a CSS z-index to advice plugin loading order. That way I could use currently existing layers and load them in my specified order to make sure the API-Layer executes before my Frontend-Layer.
3. A serious issue is encapsulation. I took a few random plugins (not the ones distributed with the core) and I couldn't believe the huge amount of code that was present in the qa-plugin.php file. That is not good because every function there is accessible everywhere. That can lead to plugins defining functions that already existed. I even saw someone checking if the function already existed before defining it. That is indeed a pain in the neck. However, I understand that from the point of view in which there is certain logic that should be shared among all the modules. However, how can you share functionality (and even data) among different modules an a simple and up to date way? Using classes. I use the qa-plugin.php file to include all paths my plugin will need and in each of them I have my plugin model (the view and controller are handled by the modules). This approach could be used by the core and in your qa-plugin.php file you would only register which paths you want to load classes/files from (check spl_autoload_register function por more info).
4. Formalize conventions somewhere. Underneath all the technological and missing feature issues there is this cultural issue. Everybody does what they want and that only leads to more troubIe. Related to the previous item, we can still have issues with repeated PHP class names, repeated variable and function names in JavaScript, repeated HTML name attribute for input fields, repeated CSS class names as well as ids, etc. First thing a developer MUST DO when writing a plugin is choosing a plugin id/prefix. That should be a somehow short piece of text that will prefix every piece of shared code so that all the previosly mentioned repeated element do not get repeated (eg: there could be 2 plugins using the id save_button but the developers would prefix it with their plugin prefixes avoiding duplication plugin1_save_button and plugin2_save_button.
5. Related to item 1 and 2 a template engine should be included in the core. Most popular, AFAIK, is smarty but might be harder to install (I haven't used it for many years, though). Anyway, any template engine will result in view separation from the core.
6. Deprecation is our friend. Deprecation means saying Hey! This has been improved and hence, will be removed in a future version. Of course, if a plugin uses that it will stop working in a future version. However, the core will be cleaner and easier to mainting and, of course, more up to date as it won't have to cope with old ways of doing stuff. Without deprecation we would still have our brand new electric cars but they would still have holes in the floor just in case people want to push them like the Flintstones. IMO, there are functions in the core that should be deprecated (I've actually made a pull request for one in the past). Now, in order for developers to be able to update their plugins, deprecation should first be notified (IMO, the changelog is the best place... by far), e.g., a 1.6.x changelog could state Function qa_blah_blah has been deprecated in favor of qa_improved_blah_blah. The function will be removed in v1.8. A double version step I think that should be enough for developers to make the (usually small) changes.
7. I believe you should ask an additional question, similar to this one, but strictly related to architectural changes as I don't think any non-developer would understand any of the points I've mentioned before but would, of course, benefit from them much more than adding a small feature to the core. Also take into account that, as gideon has stepped aside, you (Scott) have more weight on your shoulders and you just can't add even half of the features that have already been requested in this question. Only option would be for plugin developers to handle them. Making things easier for plugin developers will lead to more variety and features, not in the core, but as plugins.
Hopefully this helps clarify the ideas I've proposed.
