Yes, I think that is the 'c2r' FFTW planner, that is what should be implemented for bug #43742.
http://www.fftw.org/fftw3_doc/One_002dDimensionalDFTsofRealData.html

@Mike: I'm pretty sure that FFTW has a special method for conjugate symmetric input. And such a method is of course faster than the normal one. The 'symmetric' option is used by Matlab to force that special method in case the input is not exactly conjugate symmetric because of rounding errors. It is not an option that simply removes the imaginary parts from the output. Even if it could be implemented as such in octave.

It's possible that Matlab is doing a test for whether the input is conjugate symmetric and using a different transform method, which Octave is not doing. Is it worth it or is developer time better spent on implementing the 'symmetric' option to force it? Maybe both at the same time. If someone thinks it's important to do automatic symmetry detection this can be reopened, but not a lot has happened here in 3 years.

It seems to me that this bug is exactly bug #43742.
In the normal case, ifft(fft(rand(128,1))) returns a complex vector. If the user wants to force the conjugate symmetric inverse transform, it should be done with ifft(fft(rand(128,1)),'symmetric'). That is precisely bug #43742. I don't think there is any other appropriate way to do this. Am I missing something? Closing as a duplicate.

I do not think that removing the imag part if small is safe. The problem in fact is the choice of K. But, there is no heuristic. In xhat of the original example, xhat(1+i) is exactly equal to conj(xhat(n+1i)). This should be the check and the only case in which to apply the zeroing of the imaginary part.
As a second step, I think to remember that there is a proper function in FFTW to manage this case, which does not compute at all the imaginary part, but Octave does not use it (at least, when I submitted the report).

We can check if max(abs(imag()) is smaller then K*eps, and zero imag() if the answer is yes.
But how can we set K? Is it depend on vector/matrix size?

No, there is no detection that the input is conjugate symmetric. If the (ifft) input array is complex, then a complextocomplex inverse FFT is done and the output is complex.
It might make sense to add some heuristics to detect some of the symmetric special cases, if not to choose a different function then to at least clean up the roundoff errors in the output.
Also note the roundoff error in double vs single:

If x is a real vector, say
then
has the property xhat(1+i)=conj(xhat(n+1i)). In this, it seems to me that Octave uses the rfftw transform of FFTW. But if we now compute
we get a complex vector with spurious imaginary parts. For comparison, Matlab gives a real vector. Would'n it possibile to use an (inverse) rfftw transform of FFTW? Or, alternatively, check the input and return only the real part? Notice that this report is related to #43742.
Marco
