Caution: Lots of text ahead. Also, I could use some input from smart people 
We've had (and still do have) tons of work, so I couldn't put much time aside for these compounds. However, over the past weeks several clients have required us to put facades on CAD buildings. The CAD people seem to have trouble with this, so we take care of it. This kind of thing comes up more and more because we get good and very fast results, all thanks to the building generator compounds.
We've used them on some rather high profile projects, including a $40 million building, which we received as a simple box layout and outfitted with fully procedural facades based on architect drawings. Unfortunately, I'm not allowed to show any of the work we did
So I now have production experience with the system, and apart from a few missing features, there are two main problems: performance and usability. Usability is the biggest issue: You can get almost any result you want, but the node tree gets complicated on anything but the simplest facade. Because of these problems, I'll rework a lot of the system. In its current state I don't think anybody except for myself could make somewhat efficient use of it.
I'm wondering about a few core questions, and it'd be great if someone had any pointers in the right direction:
1) The system uses integers for a lot of things. Select Case nodes then make decisions based on these numbers. Unfortunately, numbers are not very user-friendly. Are there ways to do more with strings? I would love to be able to write "lower_floor" into my custom attribute, rather than "1". Anybody have any tricks up their sleeve?
2) Nodes need to pass a lot of attributes between them. I believe I had previously brought up the idea of using a 4x4 matrix to encode and decode up to 16 attributes (at least 7 of which I need for actual SRT information). I still like this idea because I could have an encoder compound with 16 inputs and one output. This one output is easy for users to connect to other nodes, which is great. Unfortunately, 16 attributes will likely not be enough. However, if I were to use custom attributes, I'd have to also use Set Data nodes, which require Execute ports. I don't see how I could then have a simple encoder compound with one output port that can be connected to another compound. I think I'd need two output ports: one to Set Data, the other to connect to other compounds (Edit: actually, this wouldn't work. I'd need one output port per attribute. That's awful!) Usability would be shot to pieces. Any ideas?
3) Regarding performance, are there any decent ways to bring scripting into the mix? A lot of the math that happens in the ICE trees is recursive, and code would be much faster to execute this stuff. Of course ICE is very cool in how it allows users to just connect my compounds together, so I don't want to drop it alltogether. Custom C++ nodes are my best bet I think, but is this the only option? I'm fine with Python and Jscript, practically no experience with C++.
Sorry for the wall of text and no pretty pictures. I'll see if I can post something during the next days.
