I completely agree about the importance of correction over beauty of converted code. In a first approach, I started developing a block analyzer to detect myhdl objects within the function context and depending on that, implicitly mute or unmute the block in the naming of its child elements. I gave up because there was a great risk of breaking the correctness of converted code. If I missed somithing , the converted code would break, and with all the funny dinamical things that Python allows, gathering all relevant conditions is very tricky.
This is why I opted for an explicit way of muting levels in naming. It’s not the common case when developing plain hardware, but I’ts very convenient when interleaving layers of logic that is completely unrelated to MyHDL. No one than the developer knows better when a layer is or is not related to the MyHDL, and this layers will commonly belong to third party an well tested libraries and frameworks that don’t want to affect the generated design with it’s internal logic. This way, I created a new generator that does exactly the same as a block except for that its tranparent to MyHDL’s signal naming scheme.
The “lighblock” generator, although don’t change the behaviour of block, required some changes in other parts of MyHDL. I added a keepname flag to block, that is True for block and False for lightblock. I addition, I made a change in _Hierarchy to take this flag into account. Here is a link for the commit for this change in my fork: