If I just try to play the level, no matter what initial moves I make, the 4 bugs all end up in a steady state, spinning in place. (Or I touch one and die, of course.) The level is unsolvable.

If I go into the level editor, make no changes at all, and immediately start test play -- the upper right bug moves differently and I can escape the initial room. I assume the level is then solvable, though I haven't finished it yet.

... and I assume this applies to all level types other than native RnD level files. It seems like it should use the same load-a-level code as the main game, thus automatically benefiting from conversion routines. (Perhaps an additional argument would be needed to specify a single level to dump, in the case of single files which contain multiple levels, e.g. SupaPlex.)

If I go into the level editor, make no changes at all, and immediately start test play -- the upper right bug moves differently and I can escape the initial room. I assume the level is then solvable, though I haven't finished it yet.

The reason for this odd behavior is apparently caused by the fact that all levels are converted to R'n'D format in the level editor, and converted back to EM/EMC format before being played with the EM/EMC game engine. Ideally, a native non-R'n'D level should be convertible to R'n'D format and back to native format without loss, but in fact the R'n'D engine is not a perfect superset of all other native game engines and level formats, so there can occur things like you described. Nevertheless, I will have a look at this, to find out the exact reason for the observed behavior in this case.

As you already mentioned, this should at least convert the native level to R'n'D format, and dump it just like it would dump a native R'n'D level. Ideally, it could also output native-level specific information (like EMC level version etc.).

I was noticing some similar problems more recently in other EMC levels; didn't comment since I was waiting to see what happened with this one.

One oddity I noticed: in src/game_em/convert.c, remap_emerald[] maps 0x08..0x0B to Xtank_[nesw] and 0x0C..0x0F to Xtank_go[nesw]. I noticed this while manually decoding a level trying to understand whether it had too few emeralds by mis-design, or by mis-conversion to RnD. There were a pair of tanks / spaceships which both appeared as "=>" in play and in the level editor, but were 0x09 and 0x0D in the level data. Does the folding of these two states(?) of spaceship-going-east into a single state cause a compatibility issue? I couldn't actually tell if they behaved differently from each other in play (as I remember, they were both in a narrow corridor which would have constrained their behavior anyway). But if the editor folds them down to one, and they were in a place where the difference was going to matter, editing the level in RnD would break it. No?