By implementing the origin colour from old implementation as default colour inside new implementation you are going to break this point of your approach:
The first thing I noticed in the screenshots is that the default colour is often almost indistinguishable from a custom colour with a similar hue: one green and the other can only be distinguished from each other with concentration.
For users who want to use several colours, this means that they have to do without the main colour and always have to choose one of the custom ones and therefore no longer have a main colour that is easy to enter in the sense that the standard markdown markup is used.
If I understood correctly, the critics of point “original highlight colour” of the new implementation wanted the old system back. Then you can simply give it to them by allowing them to decide in the settings to do without multicolour highlights.
I don’t find the solution really ideal that it forces the majority of users to no longer be able to use the normal syntax without unicode circles simply because the colour wasn’t nice enough for a minority. As far as this point ‘original highlight colour’ is concerned, it has already been solved by solving the other points, ‘text colour’ and ‘colour blind user accessibility’. So this third point is both puzzling and annoying to me.
I will not be an intensive user of multiple colours. I might use a second or even a third here and there, but that’s why I want to have the main colour that I don’t have to worry about determining. Precisely because I want it to be my main colour.
By the way: I like to switch light themes and don’t want to stick to just one just to minimise the annoyance