Whilst some colour correctors implement ACES this way (Baselight 4.3 for instance), I'm fairly certain Resolve isn't one of them..
For starters, the corrections simply don't behave like they are being applied to the data in a log state. If you take a linear ramp into Resolve as an EXR, apply Gain to it, then render it out again the result is a pure Multiply on your data, which is what you would expect. If gain/multiply was being applied to the data in an intermediate log state that ramp would be bent.
Same thing with Gamma, the result is a straight Gamma function pinned between 0 and 1. if it was being applied to the data in a log state it would be pegged to whatever linear value you are mapping to log 1.
Now you could get this same result if they were storing the data in a log state, then flipping to linear for the correction operation, then back to log again.
But, you can take a file with ACES float values all the way up to 65535.0 in floating point (The limit for a 16bit half-float image), make a correction, and render it out again maintaining those values. If they were flipping to an intermediate log state there would be clipping, with a bone stock cineon curve somewhere like 13.5, with some of the draft ACES Log encodings well up into the hundreds, but not all the way to 65535.0.
I'm not sure what you mean when you say there is no RRT/ODT in Nuke..
When you use ACES in Nuke the display is handled by OCIO, which uses a Log shaper to normalise the floating point data before handing off to a 3D LUT approximation of the RRT and ODT.
As for the current RRT being a "mess", I honestly don't agree. I understand it has a lot of "look" in it, which makes it tough to use if thats not what you're looking for, and I can see why they Academy are working on a more neutral version, but they are also implementing the "look" of the current RRT as an LMT, and I'm very glad about that.