> However, what you term an "implementation detail" is
> in fact a fundamental change to the entire paradigm of
> make: make has always been a stateless command. These
> features would make it stateful.

I thought about this some more, and I wonder could it be done in the same way as .d files for tracking dependencies? They are essentially stateful, but don't change the paradigm of make.

So for example, you have some way to generate a target.t.metadata file for each target, with contents something like this:

target.t: source.s[MD5=xyz]
target.t: source.s[size=512]
target.t: source.s[color=red]
target.t: source.s[command=s2t.pl -abc -def]
target.t: source.s[$ENVVAR=envvalue]
etc...

then in the makefile, you just "include" whatever metadata files you want same as you would a .d file, and specify how to generate metadata somehow like this:

meta[MD5]:
    md5 -i $@
meta[size]:
    wc -c < $@ # or could be builtin
meta[color]:
    color -i $@
meta[command]: # might have to be build in
meta[$ENVVAR]: ${ENVVAR} # environment variable setting at the time. needs better syntax I am sure.
meta[uservar]: hello # user variable. need syntax to distinguish commands from strings
# need a way to specify output files for metadata
# need a way to change metadata commands for different rules.

In you rules specify which metadata to generate for a particular type:

%.t: %.s %.s[size]

Of course there is still plenty of problems left, but is the above any more broken in terms of backwards compatability and statelessness than including .d files for dependencies?

I have probably missed or glossed many important issues of course.