Ok. I think I will attempt answering this myself. Given that (at least on linux), perl, openssl have gone down the same path as the rhash author (I am not sure who in fact, implemented this first), the reason for a different digest, is that, due to restricting the input message from $2^{512}$ bits to $2^{64}$ bits max, the first $512$ rows of $4 \times 32$-bit hex words of the S-boxes have been kept, and the last $512$ rows of the tables have been truncated.
I am not in the position of evaluating the security implications of this, and thus do not wish to accept this answer by myself yet (hoping for more professional input).
If however, solid user bases such as perl and openssl use it, I am inclined to suppose this is a viable implementation.
As a sub-question then, I still wonder why this has not been 'updated' as a 'version 4' or a $64$-bit input version more clearly?
EDIT: The "latter half" of S-boxes I thought were truncated are in fact, obsoleted ones from the reference code. This leads to my assumption being wrong and now for sure, it seems there is this version 4 out in the wild.
Surely, with an important hash as whirlpool, someone would have some insight into this. reference code asserts python code != {perl,openssl,rhash}!
To add to answer above, as I can't comment on it?
EDIT to Kerukuro: I can't comment?
on arch linux, (I also asked someone on another distro), I get :
cat quick.txt
The quick brown fox jumps over the lazy dog
cat quick.txt | wc
1 9 44
openssl dgst -whirlpool quick.txt
whirlpool(quick.txt)= 72687676756b91ad986f2e56df761b354b748bc20098354b017b924e82cc67ae059da85f009d1a17c0f12ec0e644c0c3a193f3fc0fee22f053edbfcd95cbf873
same intel sandy bridge (arch 64 bit distro):
rhash -W quick.txt
72687676756b91ad986f2e56df761b354b748bc20098354b017b924e82cc67ae059da85f009d1a17c0f12ec0e644c0c3a193f3fc0fee22f053edbfcd95cbf873 quick.txt
perl: whirlpoolsum quick.txt
Possible precedence issue with control flow operator at /usr/bin/vendor_perl/whirlpoolsum line 227.
72687676756b91ad986f2e56df761b354b748bc20098354b017b924e82cc67ae059da85f009d1a17c0f12ec0e644c0c3a193f3fc0fee22f053edbfcd95cbf873 quick.txt
The other examples you mention produce the expected result (python, reference nessie source).
So, just to summarise: python does catch the newlines, and for rhash, openssl and echoing, one should do for correct hashing:
echo "The quick brown fox jumps over the lazy dog" | tr -d '\n' | openssl dgst -whirlpool