The current system for core changes consists of:
- a core team leader and co-leader - leader has the last word on any change (and both have many, many years of experience both with TYPO3 as with web technology / projects in general and IMHO are really well-suited for the job)
- a product team for organizational / long-term team “management”
- a core team with < 30 people that are allowed to merge patches into the core
- a review system which requires at least one testing and one code-review vote from a core team member and another code-review and test by someone else - for bigger patches almost always more than these are actually done.
- a continuous integration system running unit, functional and acceptance tests before any merge on various different configurations (for example different PHP versions, mysql vs postgres etc.)
So basically as far as I understood, what you want is there already.
On to the topic of your examples: Yes, there is definitely code in the core that is not correct - which is basically the description of any bug and there are known bugs in TYPO3. Especially the area of multi-language, nested records, fallbacks etc. is extremely complex, as the expected behaviour is not always clear to everyone (as different people sometimes just have different use cases), the code base is somewhat older and every iteration has to be at least “migratable” from the previous version, the amount and of people willing to dig in those areas is really small and the complexity very high at the same time. If you want to contribute to solving these kinds of issues, it boils down to sponsor or provide active development in these areas - but be prepared, that just understanding these parts of the core (not only code-wise, but simply logic wise) will take a lot of time. Another thing people could do to help would be to test patches with their use cases (or at least test the sprint releases) because the core team will never be able to foresee any use case in the world.