They are actually not same on push dword [es:fs:ebx] or push dword [fs:es:ebx]. Is the behavior same for all x64 chips?

That's an interesting question - while I was pretty sure of the answer, I decided to double-check so I went to my bookshelf and consulted the AMD x86-64 manuals from 2002. They state that these prefixes are ignored. As all the later incarnations of x64 were based on this original specification with very little deviations, my guess would be that this should be the same for all of them.

Fail to test causes an error, removing wrmsr it prompts

wrmsr is a privileged instruction. You will need to ask a kernel driver to execute it for you.

If your intention was to just modify FS base for testing purposes, and if your CPU is not too old, try WRFSBASE instruction instead (it is not privileged like WRMSR).

rd/wrfsbase requires CR4 bit 16 to be enabled, otherwise it generates #UD if executed from not ring0 similarly to rd/wrmsr executed from not ring0
unfortunately mov from cr4 generates #GP(0) if executed from anything else than ring0 so no easy way to determine CR4 from usermode

but back to l4m2 question
segment override prefixes are group 2 prefixes and when more of them used for 1 instruction only the first one or the last one (I do not remember exactly whether first or last) is used so that's why l4m2 results were different (he used them in legacy mode or compatibility submode because push dword instruction is impossible in 64 bit mode, you can push only qword or word in 64 bit mode, but not dword)
in 64-bit mode CS, DS, ES, SS prefixes are ignored (but using too many prefixes and generating too long instruction may lead to #UD) and only FS and GS prefixes are treated
moreover in his second post in this thread he is attempting to destroy FS base which may lead to completely damage execution of the program and generating access violations at any attempt to access any memory referenced by FS
Tomasz posted correct way and in his sample the FS base is restored, but meanwhile the program execution may be interrupted prior restoring FS base and again access violation could occur (that could be prevented by disabling interrupts by the CLI instruction - again privileged instruction for ring0 or by raising IRQL by writing CR8 - again privileged instruction for ring0)

Your objections should be valid in general context, but please note that this was just about an ability to simply test/demonstrate the execution of these prefixed instructions under a normal user-mode Windows environment. With the sample I provided I was able to test them on Windows 10. To get the test results we do not need to worry about rare occurrences like interrupt happening before FS base is restored - if you are unlucky and this happens, you can simply run the program once more to get the results (it did not happen even once for me, though).

Wow! if you are unlucky and General Protection Fault happens, you can simply run the program once more to get the results

Sometimes the exception IS the test result. Keep a debugger ready.

Anyway fs:start crashes on my computer, so I just checked if it crash. and 26 is ignored

l4m2 of course it crashes as MSR_fs_base is nonzero so the base adds to the address of start so you get bogus pointer which generates #PF
in 64 bit everything else than FS, GS is ignored
some of these registers at some older Intel microarchitecture were hints in branching instructions to tell the CPU which branch target executed more frequently but otherwise they are completely ignored
from intel man:

Tomasz - nice, so your version of win runs with CR4 bit 16. enabled, I did not test these instructions from usermode yet... interesting ! It is also possible to install an exception handler and skip any faulting instruction...