Greetings!

*** Christian G. Warden [2025-03-31 12:58]:
>I can of course generate `date` and `user` files rather than use
>redo-stamp, but is there any reason to intentionally not support this
>functionality?  Any other suggestions?

Your case with the date.do can (and should) be easily made solely by
honestly generating the "date" file:

    data.csv.do:
        redo-ifchange date
        ... fetch data > $3

    date.do:
        redo-always
        date +%Y%m%d

That works in goredo as expected. redo-ifchange means "redo that given
target (data.csv) if date-file is changed". "date | redo-stamp" does not
lead to changing the contents of "date" file, as its stdout was empty.

As far as I remember, redo-stamp is just a hack to skip checksum/hash
computation of the file to determine if it is really changed.
apenwarr/redo thinks that "date" is changed if its inode's
metainformation (some of its fields) is altered, without checking if its
contents are still the same (unless redo-stamp was used of course).
Unlike apenwarr/redo, goredo always checks its contents (by comparing
cryptographic hash) if inode if altered.

You can treat default goredo's behaviour as "always feeding target's
output to redo-stamp". apenwarr/redo redo-stamp's it only if explicitly
asked for. I assume that:

    date.do:
        redo-always
        date +%Y%m%d >$3
        redo-stamp <$3

will work the same expected way both in apenwarr/redo and in goredo.
I am convinced that redo-stamp was just a hack to skip relatively
expensive SHA1 computation. And that hack should not exist at all.
It adds unnecessary complications to the out-of-date decision code.
redo-stamp command was left in goredo only to be able to write targets
that have to have redo-stamp-hack and be run under apenwarr/redo too.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A