These instructions are widely useful, and I agree that these are hard to emulate without operations being explicitly exposed. The suboptimal mapping on Intel hardware has been contentious in the past for the conversion and other operations, but we have included them as there's no good way to emulate them - explicitly asking @arunetm and other Intel folks for opinions here.

Just noting that in all my high performance kernels that needed f32->i32 conversion, I had to stay away from the "native" Wasm instructions due to the large overhead.

I have three kernels that need this instruction; they run at 2 GB/s, 3.6 GB/s and 2.6 GB/s when using a fast emulation. When using the "native" instruction on latest v8, I get 1.25 GB/s, 2.4 GB/s and 2.1 GB/s - very significant and noticeable penalty, and that's given that the "native" code doesn't perform the rounding that's required and I get for free in the emulated version, so the real perf delta is larger. As usual, these aren't microbenchmarks, and the conversion is merely part of the computational chain.

The instructions proposed here would perhaps help a bit in that at least my emulation can be tested vs a native rounding instruction and I'd expect these to perform similarly to existing variants, but I'm expecting these to be similarly not-useful for performance sensitive code unless it's impossible to implement the algorithm without these.

That's not really an objection to adding these, as these instructions aren't worse than what we already have, merely an observation. In the examples linked I believe the expectation is that the lowering is much more optimal than the one proposed (because of the differences in handling saturation/NaNs).

(on a less pessimistic note, if we decide to go ahead with these I'd be happy to contribute the kernels above as benchmarks for perf evaluation, we could compare "manual" rounding (adding 0.5 with the proper sign and using truncate), "assisted" rounding (using new fp32 rounding + truncate), proposed direct rounding and the fast emulation)

I think the current state of spec makes it too risky to include these. Mapping on x86 looks concerning for these instructions with the largest gap w.r.t instr count (16 & 7). We already have a significant asymmetry in spec considering costs of op-implementations on x86. I am afraid inclusion of these significantly increases the risk of hiding higher perf penalties/regressions on one popular platform vs. others limiting their usability for developers and moving away from spec goals.
The instructions looks useful from a convenience standpoint, but the use-case perf benefits and tradeoffs seems unclear. Even included, the perf cost on x86 may force users to rely on emulations like @zeux pointed out negating any benefits. Thanks @zeux for sharing the info.
I suggest not including these in current spec and re-consider for post MVP given their usefulness.

@arunetm please note that x86 lowering differs only by one instruction (CVTTPS2DQ -> CVTPS2DQ) from the lowering of i32x4.trunc_sat_f32x4_s and i32x4.nearest_sat_f32x4_u instructions already in the spec. The other instructions are needed to handle the difference between out-of-bounds behavior of x86 conversation instructions (return INT32_MIN) and WAsm conversion instructions (saturate between INT32_MIN and INT32_MAX and convert NaN to 0), and to simulate the floating-point -> unsigned integer conversion missing on pre-AVX512 x86.

Without i32x4.nearest_sat_f32x4_s and i32x4.nearest_sat_f32x4_u in the spec, developers would implement them as i32x4.trunc_sat_f32x4_s(f32x4.nearest(x)) and i32x4.trunc_sat_f32x4_u(f32x4.nearest(x)), which is strictly worse on all platforms, but particularly so on pre-SSE4 x86.

lowering of i32x4.trunc_sat_f32x4_s and i32x4.nearest_sat_f32x4_u instructions already in the spec.

Did you mean i32x4.trunc_sat_f32x4_s & i32x4.trunc_sat_f32x4_u here? Unfortunately these ops are highly expensive to implement on x86 and we have open issues discussing their tradeoffs #173 . We need to clearly understand their real world implications regarding perf cliffs before including trunc instructions. We may be compounding the problem by adding the new ops that rely on these. Given that we cannot assume AVX-512 instructions broad availability, the extra cost of handling out of bounds will make it even worse.

Agree that not including these will force developers to choose workarounds that may not be ideal on certain platforms. IMO, its a a better tradeoff than letting them be vulnerable to hidden perf cliffs on certain common platforms when they rely SIMD anticipating consistent performance gains. Also, runtimes always has the option of adding platform specific optimizations in these cases where developer expectations will not be broken by the spec and only enhanced by implementers.