The long term Core contributors have a general understanding of what parts of the Core codebase touch or could potentially impact consensus between nodes on the network. However, consensus is "slippery" and there have been examples in the past where changes were made that weren't considered to be consensus critical at the time but turned out to be. MCCCS highlights some of these examples in the answer above.
Pieter Wuille discussed the challenges of defining what is consensus and what isn't on the Chaincode Labs podcast in January 2020.
One of the things I think learned from that is specifying what your consensus rules are is really hard. That doesn’t mean you can’t try but who would’ve thought that a configuration setting in the database layer you are using actually leaked semantically into Bitcoin’s implicitly defined consensus rules. You can attribute that to human failure of course. We should’ve read the documentation and been aware of that.
We can talk about the boundary in trying to abstract the part of the codebase that intentionally contributes to consensus but it is very hard to say clearly this code has no impact on consensus code because bugs can leak. I think one of the things to learn there is you really want software that is intended for use in a consensus system where not only you have the requirement that if everyone behaves correctly everybody accepts the right answer but also that everybody will agree about what is an invalid piece of data in lockstep.