I’m hoping the first number 1 is correct, and the answer to the second number 1 is no.
Adding a CPython component would be a great benefit to Grasshopper (likewise adding RhinoCPython to Rhino, but keeping RhinoPython)
Replacing a GhPython component with a CPython component could be a nightmare, even if there is a great bridge to allow CPython to call into .Net.
I’m assuming the Rhino and Grasshopper APIs will be compatible in any CPython and IronPython.
So what I did to write Python 2 code that was Python 3 ready, was try to write pure Python code, that:
a) doesn’t use any Python 2 syntax that was deprecated in Python 3 (e.g. print functions instead of print statements),
b) doesn’t use any Python 3 syntax not supported in Python 2 (e.g. type annotations, raise from, f-strings, and the Walrus), and
c) where there’s a free choice of Python 2 options, compatible code should use the Python 2 syntax that gives the Python 3 behaviour (e.g. class MyClass(object) to get ‘new style’ classes, that are just classes in Python 3).
However, to get things done with Rhino objects, eventually I needed a .Net System class (e.g. to define what a standard Colour was). It’s not impossible to create a CPython System .Net compatibility layer, but Iron Python / CPython compatibility is a far harder challenge than pure Python 2 / pure Python 3 compatibility.
It’s entirely possibly to have seemingly valid code, and still encounter devious and subtle differences in run-time behaviour between Iron and C Pythons, due to implementation details, e.g. the difference in when the garbage collector is precisely called (if the code base calls del on a file wrapper instead of just using a context manager - this wasn’t my code).
Another point is, CPython 3 users will want to use pip. Care should be taken to add the setting to pip, so it installs CPython only libraries in a dir that’s not in the IronPython sys.path
It’s already possible for plug-ins to break each other when two different Python versions share a directory on sys.path (and e.g. the user or their plug-in installs numpy to one).
If compatibility is possible, I would:
a): add a core/common directory low down on both sys.paths, for Rhino/ GH libraries that are compatible (and pure python libraries). This still allows each individual Python to import and override anything specific to itself that it needs beforehand, from its own dirs higher up sys.path
or b) Ship both Pythons’ core libraries compiled. CPython won’t import IronPython .dll files and likewise IronPython won’t import .pyc compiled modules. Does pip have a setting to prefer binary wheels over sdists where there’s a choice?