So, NeoLemmix has partially supported alpha blending for terrain for a while. But the current implementation is far from ideal, with the result being that using alpha blending on terrain - even ignoring the lack of editor support - is not practical (on the other hand, it is practical for objects, as the visual appearance of them has no impact on physics and the poor editor support is only a very minor annoyance rather than a huge handicap). Indeed - I originally designed much of LPVI's terrain with alpha blending, but when it became clear NL's support for it on terrain was not good, I ditched it (on the other hand, the objects still do use alpha blending).
The current implementation, when loading a terrain piece, generates a physics image for it - any pixel with an alpha value of less than 128 is non-solid. When rendering the visual map, the image is used as-is (ie: including alpha < 128 pixels), but any pixels that are non-solid according to the physics map are subsequently erased. This means that, if one pixel were to have several semi-transparent pixels overlaid on it, such that the combined alpha is >= 128, it would still be treated as non-solid (and thus erased). Much the same also happens with steel or one-way pixels. Essentially, the physics map - from the very point of loading the terrain - is completely blind to alpha < 128 pixels, even if after blending they'd result in a pixel with alpha >= 128.
I've now written code that averts this, and generates the physics map based on the post-blending image. It's got some pretty creative stuff going on to handle steel and one-way walls correctly - and I am personally 100% satisfied with how it handles them, at least based on my testing so far. It's hard to explain it, but essentially, it's pretty much that "steel" and "one-way" are treated as color channels would be in a traditional image, with "solidity" being treated as the alpha channel - and the level's terrain layout is drawn as this kind of "image". Then, any pixel with "solidity" >= 128 is solid; and any pixel where the steel or one-way channels respectively are at least half the alpha value (this sounds weird when I write it, but it's what gives the correct result) become steel or one-way, with steel having priority if this is true for both channels (akin to the current non-blended case, where steel also has priority over one-way if both occur on the same pixel).
The only case that's iffy is when Simple Autosteel comes into play - and that's a very rarely used setting these days (to the point where the editor doesn't even support it). When Simple Autosteel is in effect, any solid pixel that's ever had a pixel of steel drawn to it, will be steel, unless it's subsequently been completely erased. Honestly, the best rule here is - don't use Simple Autosteel.
One suggestion I recall hearing mentioned, was that any pixel that's solid should then be made fully opaque. I disagree here - any opacity high enough to be treated as solid is still pretty visible.
This is in the feature/improved-terrain-alpha branch.