Interestingly, without CC 32 Controller, the CC18 doesn't work either.
That makes no sense to me. Oh, well. Read on. For that particular problem, we may be able to reroute CC32 to an innocuous message using TenCrazy's CCMap MFX. i don't know that you'd want to add another layer of ACT complexity at this point. Not just yet.
You've got a real balancing act going on here. Walking the tightrope among what Rapture doesn't want to see, what the GR20 transmits by design, and the features that you want to connect between hardware & softsynth. There are other (very useful) transmitted MIDI messages that we haven't even touched upon yet.
FWIW, I never thought that CC32 is causing any problems, but stick with whatever works. I know that CC32 can't be MIDI Learned under direct MIDI parameter control. But it can be used as a Source in Rapture's Modulation Matrix. The same goes for some other messages (CC120, CC121, etc.). That implies that Rapture wouldn't clam up upon receipt of them.
The GR20 manual seems equally contradictory. The MIDI Implementation Chart shows CC0 & CC32 transmitted, but only the MSB [CC0] received. Elsewhere in the body of the text, it only mentions CC0 for bank changes. One good thing about Roland manuals is that nearly everything that you need is spelled out in the detailed MIDI Implementation section.
The downside is that you have to speak fluent hexidecimal to understand it. At least I see where those RPN Pitch Sensitivity messages were coming from. As it turns out, you may only have to block CC0/CC32 on your GR20 Basic Channel. Moot point, if you're using Rapture's Multitimbral mode (with a "basic channel" always locked to MIDI Channel 1).
I have a few other things to explore. Active Sensing messages can cause havoc in some configs; we may have to end up blocking that. I have to look a little deeper into how the All Notes Off, Omni On/Off messages are sent. That should use the same procedures as my GR-1. Gives me an excuse to break it out.