No need to defend yourself, I share this sentiment as well. If I'm going to spend time writing and reading a lot of code in a new learning language, I want my previous knowledge to be somewhat reusable.
For this reason I was able to get into Odin as opposed to Zig because of some similarities with Swift Syntax as well how easy it is to parse.
The less I need to rewire my brain to use xyz language, the greater the chance of me getting into it.
If my life depended on it, I could get over such a shallow reason to dismiss a language but fortunately it doesn't and that's why I write Swift rather than Rust.
That's a lot of code for a PR, though i should admit I have made PR's being half that size myself.
Personally I think it's difficult to address these kinds of PR's but I also think that git is terrible at providing solutions to this problem.
The concept of stacked PR's are fine up to the point where you need to make changes throughout all yours branches, then it becomes a mess. If you (like me) might have a tendency to rewrite your solution several times before ending up with the final result, then having to split this into several PR's does not help anyone. The first PR will likely be outdated the moment I begin working on the next.
Open source is also more difficult in this case because contrary to working for a company with a schedule, deadlines etc... you can't (well you shouldn't) rush a review when it's on your own time. As such PR's can sit for weeks or months without being addressed. When you eventually need to reply to comments about how, why etc.. you have forgotten most of it and needs to read the code yourself to re-claim the reasoning. At that time it might be easier to re-read a 9000 lines PR over time rather than reading 5-10 PR's with maybe meaningful descriptions and outcome where the implementation changes every time.
Also, if it's from a new contributor, I wouldn't accept such a PR, vibe coded or not.
It's particularly terrible in SwiftUI context nowadays but you can also make it chuck on something as simple as a .map(...)