Description
While I think this could be considered a feature request, you can also take this as a question. In the README under portability, you describe reasons for not removing member from existing modules.
Qt.py does not hide members from the original binding. This can be problematic if, for example, you accidentally use a member that only exists PyQt5 and later try running your software with a different binding.
When I read that I immediately think that is a great argument for enforcing a common API. You're probably not going to hit 100% compatibility, but you can probably get it close. A similar project QtPy seems to approach it in that manner. Here's an example, if I'm developing an application in a Qt4 environment using Qt.py, It's very easy to accidentally write code that won't work in a Qt5 environment.
>>> import Qt
>>> Qt.QtWidgets.QWidget
<class 'PyQt4.QtGui.QWidget'>
>>> Qt.QtGui.QWidget
<class 'PyQt4.QtGui.QWidget'>
If I want to write even simple code that will work under both Qt4 and Qt5 I have to be very careful to check which module a given class lives in under PySide2. This is not only more error-proned because it requires the developer to make a decision, it makes converting older code harder because PySide/PyQt4 code implicitly has classes in the wrong modules. (Assuming we're saying that the PySide2 is correct).
Anyway, I'd certainly love to see a stricter api enforcement, but it would be good to get a better explanation as to why this is a bad idea. My organization is also in the VFX industry and we're trying to decide whether to go with QtPy or Qt.py and this is a big sticking point for me.