I think the C# feature you are thinking of is #region. While I wouldn’t advocate cramming all kinds of things in the same file, it might be worth also considering why this is actually a problem. I think there is a bit of a difference between doing this in an OO world vs a functional world. Some reasons why you would work hard to extract anything you possibly can include:
• Reducing the size of the things you have to reason about as a whole (which is a class mainly due to the amount of mutation that is or can be happening)
• increasing reuse opportunity by being able to use the extracted code in a different context
• increasing composition options by being able to configure more easily how extracted components are combined via IOC or similar.
Having regions in a class is a strong indicator that you can improve any/all of the above factors and due to those reasons we often find ourselves taking any opportunity to separate anything even if it might make more sense not to in the absence of reasons created by the language constructs.
I’m not sure what the answer to your original question really is or where that should really land (especially since you are looking for a particular persons approach and there are good answers here already), however I would probably rethink the relevance of the region story and reconsider how many of the issues that drive that notion in C# are real problems that should force us to move things into another file when already our units of reasoning, reuse and composition are smaller.
