> Not every project can afford this.
You expect to send a big PR to someone without him being aware of the context or without being available to discuss your solution?
> I really doubt that this is true for large, legacy code bases, where one is only familiar with a small part of the system.
Reviewers should already be knowledgeable about the part being modified. If no, the review is just for checking for antipatterns in the code, or badly written tests. A bit useful, but can be unnecessary in high trust (or keen on accountability) workplaces.
It is not that I expect it. But instead, it is just about being realistic about how real world projects differ in workflows and conventions. If what you describe is not available, then the next best thing is to make the reviewer aware of the context and solution by means of small commits with sensible descriptions.