Is your feature request related to a problem? Please describe.
Consider the following table:

> echo [[filestem extension basename]; [spam txt spam.txt]]

#  filestem  extension  basename
---------------------------------
0  spam      txt        spam.txt

The basename column can be written as a combination of filename and extension:

> echo [[filestem extension]; [spam txt]] | insert basename {
  echo [ $it.filestem $it.extension ] | str collect '.' 
}

#  filestem  extension  basename
---------------------------------
0  spam      txt        spam.txt

Now when we change the filestem:

> echo [[filestem extension]; [spam txt]] | insert basename { 
  echo [ $it.filestem $it.extension ] | str collect '.'
} | update filestem eggs

#  filestem  extension  basename
---------------------------------
0  eggs      txt        spam.txt

, naturally, it updates only the filestem column. To propagate the change into the basename column, we would need to run the insert basename { ... } again to update the derived column. In this case, you could just update the filestem before insert but it could be problematic in more complex pipelines or if you have the table e.g. cached in a variable.

Describe the solution you'd like
My suggestions is to have "dependent columns" -- columns defined as operation on other columns. Modifying the table fields would update the dependent columns without manual intervention. The above example could be written like this:

> let fn = { echo [$it.filestem $it.extension] | str collect '.' }
> echo [ [ filestem  extension  basename = $fn  ]; [spam txt]]

#  filestem  extension  basename
---------------------------------
0  spam      txt        spam.txt

> echo [ [ filestem  extension  basename = $fn ]; [spam txt]] | update filestem eggs

#  filestem  extension  basename
---------------------------------
0  eggs      txt        eggs.txt

So it's basically like a command-line Excel. Notice, I'm supplying values only for the first two columns. The dependent column would be fully automatic and writing to it would throw an error.

Describe alternatives you've considered
None :-D

Additional context
I came across this problem when thinking about the path commands revamp (#3219). It would allow to have duplicate fields in the path table, without worrying about updating basename after updating filename or extension. Apart from the basename example, for example, the column dirname could be constructed from a parts column, where parts column would contain the path pieces split by the a path separator.