During the 70s we hade (coal) grills where one could adjust the height of the grill by moving it up and down with ease. That simple functionality seems to have disappeared. Look at the common Weber grills, Green egg, Landmann, you name it. They all have fixed height on the grill.

The solution, it is said, is to put the coal to one side. Why? I ask. Why not just raise or lower the grill and use the whole of the grill.

Time to, not invent, not reinvent, but just simply pick up a solution that worked 40 years ago and still today.

Addendum:

Without being a historican I guess that changing the distance between the fire and the meat has been done since fire was put in use for cooking.

Dotnet lacks a good canonical deep copy method or lib.

There are some solutions like
What you you find on Stack overflow
and simple libraries that I have not tested.

There is Automapper which does deep copying and a boatload more. My beef with Automapper is its singleton behaviour. Either I have misunderstood how it works or there is no way to use it throughout a 3 layer solution where there is no assembly that knows all other assemblies.

Why not have a process listening to your development folder and stash every change (except bin, obj, cache etc.)?

This way one can roll back and forth throughout a whole day or week or even month to find the spot where something worked or something was changed.

Name the stashes in such a way that a nice little GUI can list the stashes and some some more information, like which files were touched.

Praise where praise is due: Rider from Jetbrains has it.
Since they provide the IDE they can do some clever thinking about how to group changes. With a file listener it is hard to tell if 2 file change close in time is one or two changes. Nevertheless; it doesn’t have to be perfect. Stashing every change takes you a long way to finding that change that ruined your day.

I dare say all main code editors today use the document metaphor; text in a document read from top to bottom.
I dare say time has come to drop this metaphor to a more object oriented or data flow oriented one.

When writing a class in an object oriented language the resulting document usually, contains the properties in the top and the methods below.
This means that when looking at the code reading a property name means it is easy to read other properties as they are close by in the document. But is this really what you want? – isn’t the methods using this property what you want to look at?

Now say you are debugging the Save method. There is a great chance you have method Restore (alphabet wise R is next to S) on the monitor; despite you being totally uninterested in them.

What you instead want to have before your eyes and withing a keystroke are the properties User and IsAdministrator and the method Validate; because they are part of the data flow method Save uses.

You are probably also interested in who calls Save and who is called by Save.

My proposal is this:

When you are working with a method, in your vicinity you want what Save reads and manipulates. Any property is shown in a window above the method you are working with. To the right you have a list of methods, and possibly some code, to all methods that are called from the method you are working with and to the left you can see all ways to call your method.
Equally easy to see and navigate to are the parents and descendants of your class.