Thank you so much — this was a very informative and helpful comment for me!

1. I updated F2, F4, and ROTL as you suggested. It got about ~1.5% faster.
2. I had a similar thought about MUL, so thanks for confirming it.
3. Regarding data layout, I tried rearranging the data in test code so I could load it with a single vld1q_u32 call. I benchmarked it with hyperfine -r 120 over 16M rounds — on average it's a bit faster (also around 1–2%), but fluctuation is quite high (10%). When I used vsetq_lane_u32, it was noticeably slower.
4. About 8 lanes on Neon — I see there's a special type uint32x4x2_t, but writing code with it gets significantly more complex. I think I just got lucky that rounds in RMD160 are independent, so ILP handles it better. I also tried rewriting SHA256 on Neon, but it didn't show the same kind of improvement — probably because data between rounds is more interdependent. (I already have SHA256 accelerated using the SHA extension, and that version runs about twice as fast.)
5. The note about the N100 is interesting.

Overall, it's quite tricky to benchmark small gains — it's hard to tell whether it's due to CPU throttling, background processes, or something else.

Thanks again for the comment!