why it is not possible?

So the problem is the need to do a polling on some I/O address in order to sync and read data from disk?
I ever guessed that disk fdc takes care of disk related operations like go to sector, read something in a buffer then the cpu has to read this.
while this is requiring full CPU attention it does not mean that interrupts should be disabled all the time.
maybe it is a problem of addressing disk drive using a BIOS instread of directly talking to the controller?

to me the process of polling is similar to the same i use to wait for the VDP command ready flag.
I can implement by doing the polling with ints disabled and this prevent me to execute some interrupt driven operations
I can implement by doing the polling, and for each poll cycle to briefly enable ints, and this allow to catch for interrupts

It's a matter of implementation not a real tech limits.

Is this the same for Disk Drive I/O ?
Assuming a very light interrupt routine, just to play psg, can the disk management stuff made out of sync?

yes, this is possible with enabled interrupts EI.
the copy of the 512 bytes of the sector must go with DI. a sector takes roughly a video frame. this looks good.

yesterday I thought the topic was digi wav, but a vblank interrupt chiptune player is possible
at least in hardware coding, what the diskROMs do is another question

tell the WD to fetch a sector
and then ask whether data is ready
all this goes with EI.
if data available, then go DI and copy the sector

now, if right before that DI instruction you got hit by interrupt, the WD will tell "you fetched data too slow".
no problem, send the command again and wait for another revolution.
and waiting for it again goes with EI.

and I think THAT issue is where diskROMs go DI, avoiding this error handling
they go DI already in the moment of issuing the command.
and the worst case for the sector to arrive is one revolution, 0.2 seconds!
THAT must be why the keyboard always looses chars.

otherwise tests smell like diskROMs nicely enable interrupts after every sector.
e.g. hbd 50, poke &hfc9a,&hc9 does remove the LED OFF CALSLT and save cpu time, and then the disk transfer speeds up a bit.
the poke would make no difference if multiple sectors would be done with DI.

while the sector slips under the head, the z80 must directly read from the head.
there is no way this can be interrupted.

the controller is like 1 byte of buffer.
now if it had a counter register telling which byte number this is in the sector, then one could make funny partial reads.
then coud be interrupted by line interrupts lol
and try read these bytes in the next revolution

cannot believe!
i've ever though that a fdc controller advantage over the tape I/O driven by z80 was the ability to tell the FDC, "Please read a sector" and the operation is handled by the latter.....
You are telling me that the cpu must synchronize reads at the correct speed via kind of polling.
what a sadness.....
that what i define a very stupid controller!

That's just how FDCs work, even on modern systems like PC.
In fact, the MSX turboR FDC is PC-compatible (yes it is 1.44MB capable).

Info provided by GuyveR800