Now, I have checked the chips of the boards and it seems that not the GPU is responsible for the "black box" glitch.
The two MV2F systems and the two AES systems have the same chip set but act differently when shrinking a sprite.
The only difference is the BIOS (SNK BIOS or UniBios), all systems with SNK BIOS show the glitch and all systems with
UniBios doesn't show the glitch.

MV1-ACH > NEO-GRC,  NEO-MGA,  BIOS: SP2-S2 SNK Bios > shrinking causes graphic glitch 
M1-FSZ  > LSPC2-A3, NEO-B1,   BIOS: SP2-S2 SNK Bios > shrinking causes graphic glitch 
MV-1C   > NEO-GRZ,  NEO-YSA2, BIOS: UniBios         > shrinking works

#1 MV2F > LSPC2-A2, NEO-B1,   BIOS: SP2-S2 SNK Bios > shrinking causes graphic glitch 
#2 MV2F > LSPC2-A2, NEO-B1,   BIOS: UniBios         > shrinking works

NEO-0 	> LSPC2-A2, NEO-B1,   BIOS: Debug SNK Bios  > shrinking causes graphic glitch 
NEO-AEC > LSPC2-A2, NEO-B1,   BIOS: UniBios         > shrinking works

With that conjecture in mind I have replaced the the SP2-S2 bios chip of the MV1-ACH board with an UniBios Chip
and after that the glitch was not visible anymore. Obviously Razoola has improved "something" in his UniBios
what fixes that shinking glitch.

Seems that if I want to be sure that shrinking works also on systems with regular SNK bios, I have to set all unused tiles
of the shinked sprites to transparent and deactivate autoanimation. DATlib provides a function to manipulate SCB1 data
with "SC1Put(addr, size, pal, data);". Would it be possible to do it with this funtion, HPMAN?
If yes, could you please post a sample code for: sprite no. 150 / tile 1 to 6 are used / tile 7 to 32 are unused?