Making a new own version of Krita would bring lots of challenges: like worrying about upcoming Qt 6, how to make Krita to have a decent speed on MacOS and what to do now that various things slowly but surely give up on OpenGL. Moreover it’s just duplication of effort. Forks are a radical measure; they are good if you either disagree completely with the design (I don’t mean just UI here) or direction the project is going in, or disagree with the team/maintainer, and there is no way to handle disagreements in some other way (like here, with Python plugins, which can change the UI). Here, if you figure out how to make the menu bar, or if you give up on that, you can do everything else easier in a plugin, which you’d only need to keep compatible with newer Kritas.
Other people’s advice is really good, maybe except for the style thing, because if I remember correcty, breeze style is not available on Windows because it has too many dependencies (is too heavy). I must admit I don’t know much about it, but it might be more difficult than one can imagine, I believe someone once asked why Krita won’t make their own style, and the answer was, it’s just too much work to make sure it actually works correctly. I think the relevant docs page would be Styles and Style Aware Widgets | Qt Widgets 5.15.5 rather than Qt Style Sheets | Qt Widgets 5.15.5 . One of the pitfalls for one’s own style is the Blending Modes comobox; Krita had multiple Linux styles blacklisted (as in - if it was the current style on the system, Fusion would be used instead of that style) because they couldn’t handle that combobox (I believe even Breeze was once blacklisted because of that? But I’m not sure).
If you follow @AlansArtLog advice, here is a list of very simple and small things you could implement in Krita to get a hang of it: Beginner coding tasks in Krita: easy and short feature requests, ready to implement .
You could also just go straight to making the plugin. It would be especially awesome if you could make it modular - as in, the user could install or use just some parts of your plugin, and not all. (And be able to use it together with native Krita’s functions).
Oh btw, the strokes in the Brush Presets docker, I believe there were other artists asking for it. There is a chance you could implement it in main Krita as an option (like right now there is Thumbnails and Details, there could be a Stroke mode).
EDIT: some of the things you plan are actually things one would need to extend the Python plugins API for (like changing settings in a brush preset, or maybe even painting with that brush using Python?). It would be still easier than maintaining your own project, though, and it would be beneficial for other Python plugins creators, so it would be really awesome if you decide to go that route.