While the access itself would be easy to add, it is against the design principle of snapd to do this (specifically, the communitheme snap should provide its theme as a content interface for other snaps to consume, not have the desktop interface that is provided by core expose access to other snaps). It seems like snaps (or theme libraries) would need to be patched to know about the non-standard /snap/communitheme location whereas exposing it as a proper content interface avoids that since the content is bind mounted into the snap’s runtime environment.
As @kenvandine mentioned, work is ongoing for a big ‘themes’ snap. I don’t have the status of that work, but in Budapest we specifically mentioned the communitheme snap as one of the themes to be included in that snap. You mention elsewhere that the theme is evolving fast but that isn’t a problem at all: snaps are designed to move as fast as the publisher wants so just update the communitheme within the big themes snap and everyone benefits.
Lastly, patching snapd isn’t going to be as fast as you desire (probably)-- 2.32 is desperately trying to make it through the SRU process and it has been delayed a long time. That means this is most likely 2.33 material, which I suspect the theme snap will be done way before that.
For these reasons, my opinion is -1 on this change to snapd. Instead, please focus on helping to make the big themes snap meet your needs. Do note, while I gave my opinion, if you feel strongly that patching snapd is the right thing to do, please escalate to @niemeyer (as snapd architect) who can decide the path forward.