What I'm suggesting is making it so we can specify certain variables that retain their value when a turf is replaced. (So that the value of the variable isn't set back to its initial value in the New proc.)
Some built-in vars already function this way. i.e. contents and loc.
It's easy to see how useful this could be. For example, if there is a level of light shining onto a turf, when it changes to a new turf, the amount of light shining on it wouldn't change, so the variable for light should remain the same. I'm sure there are many uses for this feature.
It could be implemented as a simple type specifier such as how tmp, const, and static currently function. The keyword 'dynamic' could be used. (Similar to the 'dynamic' keyword in C++ and similar in usage.)
So, the following code would be how to use this feature:
turf
var
tmp
tmp_var
dynamic
dyn_var1 = 0 //optional default value set when world is created
dyn_var2
dyn_var3
Of course, there are currently some ways to do this, although, all of them cause the code to either become needlessly inflated or cause other issues that make them unfeasible.
Method 1:
turf
New(L, some_var, another_var, random_var, too_many_vars) //easily inflated
//can't forget to always pass every parameter in new
//can't have parameters for other purposes
..()
dyn_var1 = some_var
dyn_var2 = another_var
...
This method causes obvious problems. It inflates the new proc, because it needs another parameter for every new variable. And since those parameters are taken, you can't use them for other purposes. Also, you have to remember every time you use new to make a turf to pass the turf's own variables. Many obvious problems.
Method 2:
turf
Del() //also easily inflated
var/temp1 = dyn_var1
var/temp2 = dyn_var2
var/temp3 = dyn_var3
spawn() //spawn causes write-protection issues
dyn_var1 = temp1
dyn_var2 = temp2
dyn_var3 = temp3
..()
This causes the code to become inflated as well, since you need an additional 2 lines for every variable. This is better than the first method, since you can still use New() without taking up countless parameters. And since the assignments can't take place until the next New() proc is called, they have to be spawned so they occur after. Spawning is not what we want here, since the variables should be set before the New() proc is called.
Method 3:
For every turf, it could have an invisible object on it that contains all of those variables that is created when the world is created. However, this causes the added overhead of needing to create objects in a loop for every turf in the world, which could cause a slow start-up. There's also the problem of having to use an extra level of indirection to access the values, not to mention you'd have to search the contents to find the object before you could access it.
There are other methods, I'm sure, but none of them are useful for maintaining a solid code base.
The only nuisance is that you have to call copy in the constructor. If you override a turf's constructor and deliberately don't call ..(), you need to remember to call copy(). You also have to maintain the dynamic_vars list, but either way you have to indicate which vars are dynamic.