Best demos

I did experiment a bit with trying to load from disk while playing music.
If you manage the filesystem yourself and do "Absolute sector read" from the disk you can build a list of sorted blocks to read and interleave it so that you read every other sector on the disk.
That means that you are guaranteed to get the block within 3 frames, but it could be 2 on rotating disks and even less on other storage mediums.
I'm not even sure if you need to interleave them, the gap that already are between sectors might be enough in which case you get down to 1-2 frames, but then your music player have to be lightweight enough to fit in the sector spacing.
The problems to overcome is:

• You don't know how much time have passed. (Probably easy to solve by checking odd/even frames.)
• The disk keeps spinning whether you like it or not so you can't wait for vblank to synchronize the music. This means that you will have to accept that the music is jittery and may sound like crap or you just have to compose that part of the music to be played with sector synchronization instead of vblank. (45Hz +/- 1.5%? + whatever happens at the index pulse.)
• You are locked down to whatever filesystem you choose to support. OTOH you can probably assume that you can do random access in less than one frame if it isn't FAT12 and have a different routine for that, or test reading sectors with different distance between them to test if you have fast random access IO.

Over all I feel that it is easier to invest time in writing data compressors that are specialized for the data you use and generate as much data as possible than to mess around with reading disks on the fly.
In Baltak one effect runs entirely from the interrupt so that the main code can unpack the rest of the data needed without worrying about effects and music playing.

This I strongly disagree with.

This I don't.

It's crap for demos and even worse for games.
The only thing that makes it seem more suitable for games is that the user base is focused on them instead of making demos.
It could probably be good for spreadsheet editors and other data management applications, even outperform other 8-bit platforms in that area, but the interest for it is pretty low.

This is the really important part.
Fancy effects are cool and all, and part of the entertainment, but it is not a substitute for good music and good flow.
If you spent weeks trying to get a cool effect to work it is very tempting to milk it as much as possible, but just because it was hard to write doesn't mean that it is fun to watch.

Those are perfectly fine games. It's just that if you think about converting them to other 8-bit platforms there isn't really any big hurdles to overcome. MSX doesn't have anything special that makes those games possible.
But if you on the other hand try to convert games that takes advantage of other platforms to MSX you get a lot of interesting problems to solve.
The MSX boundaries are seldom in places where other platforms can't reach easily.

I was talking about technical limitations. Having studied the MSX architecture in detail, I have a hard time seeing the hardware margins that have not been explored yet. There may be some small ones left, but imho, nothing that would allow a significant gap with known techniques. If I am wrong, I will be very surprised but also very happy

On the other hand, there are certainly a lot of tricks to be discovered that will allow to create effects never seen before on MSX.

In my opinion it is better to do 5 super minutes than 20 minutes with lengths.
But if you can make 20 minutes super interesting with good music, I take it too.

I know that some will not agree, but personally I prefer that we sublimate the smallest common denominator of MSX2: the PSG.
But, if I had to add an audio chip, I would choose the MSX-Music (because it's the most standard of the 3 imho) or SCC (because Konami's games are so widespread that there are perhaps more SCC sound cards than any other format ^^).

If you take pre-rendering to the extreme you can even run PC demos on SCREEN 2.

Well this seems a bit like cheating :) but when pre-rendering or pre-calculating is used smart it can help.
Take a Starfield: If you do it properly you'd have to make like 3-6 floating point calculations per star. Which MSX can never manage in larger numbers. But by preparing sin/cos tables and fixing the values to fit in 1 byte you could do (partly pre-calc) multiplications that only use 96 clock cycles (not counting M1 cycles). And even then you could pre-calculate even more to reduce cycles per star per frame. (same goes for (other) 3D animations)
And with 128KB VRAM an animation can be pre-drawn in multiple frames in memory, when no high CPU/VDP usage is expected, to then display the frames fast after each other.
Don't think that the demo's on all the other platforms don't use tricks like this. But they hide it very well. That's the game!
Speaking of games: A lot of the same techniques could be used for games.

I think I've seen every "good" MSX demo, and there are some great once. But there is still a lot of room for more and better.