[Unison-hackers] More invasive code cleanup?

[Tõivo Leedjärv]

Eventually version compatibility will be broken (for example, when
switching to a more stable protocol). When version compatibility is
going to be broken, what is the appetite for other more invasive
changes? I would like to get opinions and arguments.

I am thinking of several code cleanup and maintenance changes, not all
of which break version compatibility, that can be more invasive and
need more preparation, review and testing.

Just as an example, from the top of my head:
 - Removing CTimeStamp (which has long not been used) -> changes archive format
 - system/system_win* seems to be nearly (or completely) obsolete with
newer OCaml versions and might be removed. Once that is gone, all
system/* becomes obsolete?
 - In several places in code you find FIXME and TODO markers
 - Sometimes you find comments like (*FIX: remove when Unison version > 2.40 *)
 - There is some code for functions that are now covered by Stdlib (I
assume the code is in Unison tree because it was not available in
earlier versions of OCaml)

Much of this can make the code smaller and easier to maintain in
future. Some could fix long-standing issues. None would bring in new
external dependencies.

Is there readyness to review and test? Or is the wider opinion to
leave the code alone as much as possible and only maintain it to keep
it running with newer OCaml and OS versions?

-- 
Toivo