Sure, but still, having a way within SWIG to generate both standard python binding and more cffi-friendly python could help transitioning.
That way, new projects can still benefit from the strength of SWIG that allows them to propose bindings for multiple languages with a single tool. Because, let's not kid ourselves, using specific binding libs for every single language you want to support has a cost. And in that case backward compatibility does not matter much.
All the while giving a transition path for projects still using what I would call the legacy way. Or those who want/need to poke in the CPython API.
I haven't used SWIG in 15 years, but having it emit a cffi shim would be a great way to get existing projects ported over to a more portable interface without requiring them to change anything.
That way, new projects can still benefit from the strength of SWIG that allows them to propose bindings for multiple languages with a single tool. Because, let's not kid ourselves, using specific binding libs for every single language you want to support has a cost. And in that case backward compatibility does not matter much.
All the while giving a transition path for projects still using what I would call the legacy way. Or those who want/need to poke in the CPython API.