What means "interferring"? Most - if not all - CGX based software works with a Picasso96 installed systems (like one of my A2000's). Same is true for (most) CGX aware software that I use with AmigaOS 4.1 FEU1, which has no real "Picasso96" anymore - it is integrated into the OS itself (mostly graphics library).
So I assume it is all matter of stub/wrapper design, which we have since ages between Picasso and CyberGrafX.
The entire "family" of solutions (Domino, Picasso II, MacroSystem Retina, EGS, CyberGraphX, Picasso96) which replace the built-in Amiga chip set graphics output with what used to be SVGA graphics hardware needs a very specific operating system version to work with.
The oldest solutions would support Kickstart version 2.04 as well as Kickstart versions 3.0 and 3.1. Those solutions which still saw updates in the recent past no longer support Kickstart version 2.04.
In order to make the change from the built-in Amiga chip set to the SVGA graphics hardware possible, scores of run-time patches are applied to the operating system, and the code which is hooked into the operating system also makes assumptions about the layout and contents of undocumented data structures.
For example, a set of run-time patches makes opening screens possible on Picasso96, which rely upon the specific contents of several CPU registers when memory is allocated for the screen to use. As it is, this only works with intuition.library versions 39 and 40, as built with a 'C' compiler last updated in 1987. Use a different 'C' compiler and Picasso96 will suddenly start using chip memory for screens because the CPU register contents expected by the run-time patches no longer match.
Picasso II and CyberGraphX support screen dragging, just like it does on the Amiga built-in chip set (if you can still recall that!). The code which made this work was originally developed for Kickstart 2.04 (by Thomas Sontowski), but when Kickstart 3.0 came around it ceased to work. The internal data structures attached to the fundamental screen data structure had changed (in 1992), which broke the run-time patch that enabled screen dragging support. While a solution for this unexpected incompatibility was eventually found, it relied upon a set of undocumented data structures.
The dependencies on run-time patches and undocumented data structures are going to cause trouble sooner or later if/when graphics.library and intuition.library are modified and rebuilt. There will be a need, and there arguably already is a need, to allow the Amiga operating system to play better with the kind of new hardware which we will see arriving this and next year (keeping my fingers crossed).
In Commodore's times it was already hard to make clever hardware solutions work, because the Amiga operating system was tightly integrated with the custom chip set, and there was no apparent need to go beyond it. Commodore itself failed at making the transition to what was called "retargetable graphics" (RTG for short), and 3rd party developers such as Village Tronic succeeded in spite of this. When Commodore went out of business, these third party solutions were no easier to make and evolve. I was there, and there are scores of stories about the strange bugs that popped up during development to baffle everyone involved. These run-time patches, etc. were some of the most complex solutions you could imagine.
It is no easier today than it was back in the 1990'ies to graft code onto an operating system not intended to be extensible in the graphics arena in the first place.
It cannot stay that way indefinitely: making the operating system more friendly towards the use of today's hardware rather than having the developers spent an awful amount of time jumping through hoops, will have to happen.
