I have no particular attachment to the name, and am happy to accept suggestions.

As far as export, I understand and share your concern, but not exporting it also seems problematic. For example, we could have `rfft!` accept a real-array input and return an `RCpair`. But then it's not really acting in-place, because in-place r2c and c2r transforms require padding---if you were counting on it to modify the underlying memory buffer, you'd be wrong. Once the `RCpair` is created, of course you could continue to use it for in-place transforms of the same size, so this isn't entirely terrible as an interface, but it does introduce a somewhat disturbing inconsistency. A more minor concern is illustrated in the application that I developed this for: it does a _huge_ number of FFTs and pre-allocates working storage before launching any real computation. That model would either require that you begin by making a "dummy" FFT just to get the RCpair back, or reach into `Base.FFT.RCpair` to get the raw constructor.

One option, of course, is to say that this is too many exports for the amount of functionality it adds. In which case this can continue living happily as a module in my own private code stash (which is fine). I guess the flip side is that FFTs already add a large number of exports anyway, and they don't really interact with other things.