Actually, I'd appreciate expansion on the respect in which Clojure is designed for interop with an arbitrary host. One (relatively uninteresting) respect in which that might be the case is that Clojure-the-language might not say anything about, say, what numeric types there are. Actually it does, though: Clojure supports ... all Java numeric types. And then there are two more Clojure-specific types. Or perhaps that is the sense in which it's designed for interoperation: it just says "we'll use the number types the host has".
Isn't it the case that Clojure and ClojureScript have different libraries with "different ideas" (whatever that means) about interop with their hosts? And ClojurePy yet other ideas about interoperation with Python? The hosts are very different in each case; how could the interoperation not be? (I suppose you could supply the host with a runtime that emulates aspects of the interoperation on the original host---but that's not very interesting!)
(Also, he mentions dotLisp in the post you reference as footnote [1].)
I disagree that Numbers are relatively uninteresting. In fact, I think any language designer would tell you that numerics are one of the hardest areas to get right. It's also the area where Clojure is weakest in terms of interop, I'd say. ClojureScript, for example, only has host Numbers (ie double-precision floating-point)
The main thing that Clojure does in terms of being designed for interop is to require the use of host values/objects. There are no wrapper/proxy/delegate/whatever objects. This has big implications. It (unfortunately) means that there is behavior you simply can't have in core, such as reflection or continuations. That's a big part of being interop friendly: Intentionally specifying fewer things. If you have very strict rules for how something like strings behave, then you might wind up in a situation where you need to create a ClojureString class or something like that.
Additionally, the '. (dot) special form is like a giant "INTEROP HERE" sign, which is extremely useful when porting code from CLJ to CLJS. You can literally grep your source for /\./ and find platform specific code.
What I meant is that "if designed for interop" in the case of numbers is something like "there is no design for numbers, just use the host's numbers", that's not a very interesting design. And it leads to, for instance, huge differences between Clojure and ClojureScript (as you note).
Isn't it the case that Clojure and ClojureScript have different libraries with "different ideas" (whatever that means) about interop with their hosts? And ClojurePy yet other ideas about interoperation with Python? The hosts are very different in each case; how could the interoperation not be? (I suppose you could supply the host with a runtime that emulates aspects of the interoperation on the original host---but that's not very interesting!)
(Also, he mentions dotLisp in the post you reference as footnote [1].)