1) I don't think we need to worry about the performance of creating the terrain layer. This is only done once at the beginning of the level, so it won't slow down the actual game-play.
Very good point.
2) Regarding how to treat semi-transparent pixels in the final terrain image: I would go even as far as erasing every pixel with transparency < 50% and setting all other pixels to fully solid (i.e. alpha=255). Terrain is after all the only layer where it is important to see every single pixel, so I wouldn't want to blur it against the background, etc.
This may be acceptable. I definitely agree re: erase any that end up non-solid, whatever cutoff point may be chosen for that. However, I don't know how I feel about setting a=255 for everything else. It might be workable, but I'd want to see it in action before outright saying I approve. And let's not forget - the primary purpose would be, of course, for better-looking levels graphically. We don't need to worry about the normal terrain layer being perfectly clear visually; we have clear physics mode for that exact reason - to allow artistic terrain design while also allowing people to see the functional aspects of the level, without putting restrictions on the artistic side of things.
Alpha blending is something that can be implemented very easily, aside from having to make a decision on the cutoff point to treat as solid vs nonsolid (and I will stress - I absolutely think this should be calculated from the final terrain layer image, not each individual piece). If I remember correctly, NeoLemmix *already* has code to implement a cutoff point; it's just that the cutoff point is currently set as "anything nonzero is solid". All that's needed is a few tweaks when drawing the terrain layer, so that semitransparent pixels blend rather than overwrite - and as mentioned above, this is a pretty simple change thanks to how GR32 handles blending. It would not require any changes to in-game physics, just a few tweaks to the initial terrain layer and physics map rendering.
I don't think I will change this as long as there are so very few pieces which have semi-transparent pixels.
This is a catch-22. There are few (if any) pieces which have semi-transparent pixels
because NeoLemmix does not properly support them (and has never claimed to do so - all
file formats since the single-DAT-file graphic sets have had support, but at no point has NeoLemmix itself claimed to actually support them functionality-wise). You can't say "I'll add support for something that isn't currently supported once people start using it", because they aren't going to start using it if it isn't supported. Rather, the answer should be either "yes, let's implement this"; or "no, this will never happen". Or, a possible third option - "I'm open to it, but I first want to see how much interest there is in using such a feature". I don't know about editor-side, but game-side this is already partially implemented anyway, and the remainder of the implementation could likely be done in about a dozen lines of code, if that - however, it does raise questions about how certain aspects of physics would function, in particular where partially-transparent steel pixels (or partially-transparent pixels on the top of steel) are involved. So, I could definitely understand the logic behind a decision of "don't support it" due to these complex edge-cases (which would pretty much need to be decided arbitrarily), but I do feel that a solid answer should be given on that matter.