I'm Andy Jones, one of the creators of Cryptomatte. Jonah actually spotted this thread the other day, and I just wanted to chime in to share a few thoughts, and make myself available if you guys have any questions I can answer about Cryptomatte.
A bit of background -- I'm actually a big fan of Fusion, and was a Fusion user myself for a while. So, it's really exciting to see interest in Cryptomatte on the Fusion forum. I apologize we don't have a Fusion version. Since Cryptomatte is really more like a specification than a code library, our hope with the Nuke release was that it would serve as a template, and would lead to versions in the other packages (which seems to be happening, as far as we can tell). Unfortunately, there are only so many hours in the day, and although we DO have Fusion running at Psyop, making Cryptomatte for Fusion hasn't really been something we could justify spending time on at work yet.
That said, this past spring I did spend a little bit of time looking into how Cryptomatte would fit best into Fusion. It's really great to see a working Cryptomatte node graph getting posted on a user forum, as it helps show how simple Cryptomatte really is -- especially on the comp side. Our Nuke version is basically just a gizmo (the equivalent of a Fusion macro, I think), plus some expressions and a python library. As far as making an full-fledged plugin, I didn't ever get too deep into the API back when I was comping in Fusion, but it seems like writing something with the Fuse API would probably make sense... OFX could work as well, but my overall impression is that OFX plugins never work quite as well as native plugins, unless a package is specifically designed around OFX. And OFX would probably mean distributing binaries (which isn't a bad thing, but can require some overhead to keep up with new releases.)
In any case, I think there are some good options to get something working via the api. However, my overall assessment was that the BEST way to get Cryptomatte working in Fusion would be to extend the existing Object ID and Material ID channels to support Cryptomatte-style channels natively. That seems much more in keeping with how Fusion is designed to work, with each node providing a lot of value-added functionality. Given that Cryptomatte works pretty much exactly like Object IDs (but without edge artifacts and with a table of names for IDs), it would just make a lot of sense to upgrade the existing features, rather than add something functionally superior that's not as well-integrated. IDs also require special handling, because they can't be re-sampled the same way as regular RGB data. That sort of thing would be much easier for users to navigate if the IDs are in a dedicated ID channel. Also, I'm under the impression that one of the big reasons Nuke has "unlimited" channels is to allow mattes to be passed through the comp. With Cryptomatte, you don't really need that, so a limited, but sensible set of RPF channels can actually start making more sense than Nuke's solution.
With that in mind, at SIGGRAPH this past year, Jonah and I visited the Fusion booth and pitched Cryptomatte to Steve Roberts, the Fusion product manager. We had a great chat, and he did seem genuinely interested. But as always, software development at the application level is a complex beast with budgets, release cycles, and marketing departments, so it can be a long journey from 2 people cold-pitching an idea to actually seeing something implemented in the software. So, if Fusion users are interested in seeing Cryptomatte support, I'm sure communicating that to the developers would help make it happen sooner.
In the meantime, I wholeheartedly encourage the use of Cryptomatte AOVs in Fusion using setups like what you posted, and (hopefully) the creation of a plugin using the API. Jonah and I are more than happy to answer any questions. I unfortunately can't really promise contributing dev time to a plugin project at this point, but it's DEFINITELY something we'd take an active interest in. I do suspect it would be a pretty easy project for someone who is already familiar with the Fusion API. For example, a similar discussion on BlenderArtists.org led to a prototype in about a day. I think a lot of people spend more time than that just making old-school mattes on one 3D project
https://blenderartists.org/forum/showth ... -released!
Anyway, I'd be very interested to hear people's thoughts, and I really hope this helps Fusion users feel less in the cold!