Clojurians Log v2

yes, yes (the org name is "arcadia unity" but it has a "arcadia godot" repository) https://github.com/arcadia-unity/

But, these are unmaintained. I think the maintainers moved on.

most things around ClojureCLR are not "ready for use" but it's a great starting point

Maybe you mean "no longer ready for use" in the sense that they are longer maintained? And yeah that is true of some ClojureCLR projects. My observation would be that actually the core of ClojureCLR is remarkably full featured, stable and up to date with Clojure. Ready for use 100% and there are also ports of various libraries like core.async, tools.nrepl, test.check, data.json etc readily available. What makes me miss being on the JVM is the lack of things like https://github.com/cognitect-labs/aws-api . I am optimistic that the new deps.edn tooling which can use git to consume other Clojure code (i.e. without needing to package for Nuget) will eventually help to make cross-platform libraries more common.

Indeed, the deps.edn tooling enabling git coordinates is going to help a lot here. But I'm afraid I'm a little less sanguine on the possible proliferation of cross-platform libraries. It's mostly a people problem. If one is a library maintainer and doesn't have multiple platform capabilities and the willingness to take the extra time updating/testing/etc., then there have to be more people involved and coordination in doing releases, at minimum. Who has the time? Which leaves us with fork-and-port. (Why am I suddenly thinking of franks-and-beans?) I'm guessing that is not in the spirit of 'cross-platform' that you intend. With respect to your specific example, https://github.com/cognitect-labs/aws-api, it's actually a reasonable candidate. It's actually written in a way that facilitates porting. The main difficulty in porting is platform interop. This library has a significant portion of the interop sequestered in a 'util' namespace. Do a drop-in replacement in a .cljr file and you're halfway there. (I'm basing this assessment on a quick scan of all 'ns' declarations, looking for imports of JVM classes. I would have missed any interop that used namespace-qualified class names.) Some network hacking, some I/O hacking, some thread hacking and you're ready to start testing. (90% of porting comes down to those three categories.) Go for it! (I'm happy to help by advising, but I'm already maintaining 22 libraries and I don't know AWS at the the level required to deal with this.)

Some of the AWS APIs (e.g. S3 and EC2) are actually XML-only which means you'd need clr.data.xml . I had a go at porting data.xml but got distracted. I might dust it off now that I have some free time.

data.xml does not look like an extreme (s)port.