I have used asMSX for years, and I was a great defender of that cross-assembler. But at the end of last year, as I developed a new and bigger game, I finally gave up and switched to sjasm.
Metalion, sorry asMSX didn't work out for you. I am glad you found sjasm to work well. Between fubu and I, we quashed a large number of bugs. Probably introduced some new as well 
Hopefully it's more stable now. Robsy did amazing work with asMSX, it has many cool unique features. But it was written in C by an assembler programmer, and as a result, almost all variables are global, most code modifies global state directly. There are no unit tests at all. Code is large enough that following through on what is going on is difficult.
What I did is use available static code analyzers (cpptest and vs2017 analyzer) and compiler warnings (gcc, clang, vs2017) and fixed the code until most of those warnings were addressed.
What fubu did is use valgrind on debug build to find potential memory leaks and address those.
What we want to do is to stabilize the code further, by moving all the logic to small, stand-alone, pure functions. Those functions would be composable and testable. And they would never touch any global state. All input and all output would be done via parameters and return. This would allow us to add test coverage for most of the code. Once the code is covered, we can start debugging lexers and parser, add new features like externded macros, inline sprite definitions, built-in data cruncher and so on, confident we won't break the functionality that's already working.
I understand there are better assemblers, but I don't want to see asMSX languish behind. For me it is an interesting challenge in refactoring. If we manage to make the code modular, testable and easy to understand and follow, I'll be very happy.
By the way, my most recent PR fixed broken wav writing code that didn't work since the original GPLv3 release by cjv99. To do this, I first wrote a python prototype, got it working, and then wrote equivalent C code.
Thanks for the feedback Metalion.
I hace still no clue about why the NOP bug happens, but I believe it is relates to the global state and the code tags from what I have seen. If we manage to refactor the code, as dhau says, into manageable modules it will be easier to trace that bug .
