Isn't that worse, in some sense? I'd imagine the fork would gradually lose compatibility with plugins you use for coding over months. Or are those vendors busy keeping their fork up to date with the OG codebase?
If it's the latter, that's still an extremely strange state of things.
This is speculation, but I think there's a way to do it without much pain at all. I've built a few VSCode extensions and the extension framework is extensive and robust and it has well defined boundaries. The only problem you'd run into is the extension sandbox. If all your fork does is make a sandbox exception for your specific code at the extension boundary, you will only have to keep those bits correct and then you can write the whole rest of your custom editor like you would an extension. That would mean that you get to benefit from all the existing know how around building extensions and also make keeping up with upstream a breeze.
As I said though, this is speculative and how I would approach this problem based on the work I've done, I don't know if that's realistically feasible and what they've actually done.
As a cursor user, it was annoying at first to be using a vscode fork but honestly it turned out to not really be an issue. Biggest issue was pylance not working and having to switch to basedpyright—not a major thing for me but could be for others with a lot of existing python code.
Now as the maintainers of cursor and the ones working on the fork? I have no idea but I imagine it is pretty annoying.
If it's the latter, that's still an extremely strange state of things.