This behaviour makes it awkward to write programs that make use of those properties. It feels like something that should only be set when the mouse is first enabled, which can then be changed.
A more articulate explanation from Discord:
SlithyMatt wrote:Tue May 11, 2021 2:04 pm Yesterday I learned about some undocumented behavior with sprites. As you probably know, the Kernal mouse driver takes over sprite 0 and you no longer have programmatic control over its position. You can change its size and bitmap, but that's it. It also appears that the collision mask is another part that's locked down. If you set a collision bit in sprite 0, it still won't trigger a SPRCOL IRQ when the mouse cursor intersects with another sprite with the same collision bit set. What you have to do (and you will see this in my next X16 tutorial video on Monday) is have a synchronized sprite of the same shape at the same position as the mouse cursor. This hidden sprite (as you want to update its position to match the mouse cursor every VSYNC) is the one you need to have the desired collision bits set, and then you'll get a SPRCOL when they collide with other sprites with the same bits set. This is basically what you'd want to do to make a game like Air Hockey, where you want precise edge collision detection between your elliptical cursor and the the puck. In fact, if you were to make an Air Hockey cursor with the little spindle handle sticking up, you can just make the synch sprite underneath it omit the handle and just represent the elliptical edge so that the part of the handle sticking up won't trigger the IRQ.
Natt Akuma wrote:Tue May 11, 2021 3:17 pm https://github.com/commanderx16/x16-rom ... #L186-L187 I found an offending line
So yes the Kernal will clear collision mask every time it updates the mouse