Documentation says about apodization functions:
When more than one function is specified, then for every subframe the encoder will try each of them separately and choose the window that results in the smallest compressed subframe.
So, from manual it is not clear at all if order of functions does matter or not. But it does matter.
For example
flac.exe -l 12 -b 4096 -m -r 6 -A tukey(0,5);partial_tukey(2);punchout_tukey(3) input.wav -o output.flac
input.wav: wrote 178263 bytes, ratio=0,306
and
flac.exe -l 12 -b 4096 -m -r 6 -A partial_tukey(2);punchout_tukey(3);tukey(0,5) input.wav -o output.flac
output.wav: wrote 175430 bytes, ratio=0,305
result in different compression despite the same apodization functions are used, just order is different. FLAC version is 1.3.3, wav file - https://www.dropbox.com/s/q4p1fmaqewxltdg/2_5357505388570740373.wav?dl=1
So, how this actually works? Is documentation not clear or this is bug?
BTW: your system uses comma as a decimal separator, so you should use it too: "tukey(0,5)", not "tukey(0.5)"
OK, changed dot to comma, edited my post. Anyway compression is not exactly the same.
I was intrigued by this post and tried to replicate. I found that indeed the order matters. However, in my tests, the difference was much smaller than in yours. I have a (untested) hypothesis that this is because of the way FLAC decides which frames to use.
FLAC calculates a pretty accurate guesstimate of which apodization will result in the smallest framesize, but it doesn't calculate the exact size the frame will be during the evaluation stage. If the guesstimates of the sizes of two different attempts are exactly the same, the frame that was evaluated first is taken. While the guesstimates are the same, this doesn't necessarily result in the exact same framesize. This framesize is only calculated as the selected frame is actually output by the FLAC process.
The chance that two guesstimates are the same is fairly small, and if it happens, usually the frame size difference is pretty small too. In my case, usually about 2-5 parts per million. However, in your case, this 1,6% difference is somehow 'lucky', or something else is at work here.