I don't think a book is "not language agnostic" because two particular languages aren't very good at it. C's lack of closure support is unique among any language still in use, for a variety of reasons. Java... was Java. If you weren't there you may not remember or understand, but at the time OO was at its most dogmatic and either it was an object or it was not included. Anything you could do with a closure could be done with an anonymous inner class. (Which is, technically, true. But the amplification factor on the effort and the sheer quantity of text involved to do so in Java is astonishing.) You can hear some of the echos of this in the older Ruby rhetoric, though I haven't heard it in a while.
Any other general-purpose language you'd be inclined to pick up right now would be fine.
IIRC, you end up implementing a scheme, which you can do nearly in the language of your choice, then the book covers that language you are implementing.
The book is not language agnostic because it's not language agnostic, mostly. The fact that many other languages are a poorer fit for what it's trying to teach is pretty much the definition of 'not language-agnostic'.
I don't know what task could possibly exist for which there are not significantly better and worse languages. Even today's "list of practical projects that anyone can solve in any programming language" [1] I can see at a casual glance that any of them that are not simply trivial will have better and worse languages. A definition of "lanugage agnostic" that either covers no tasks, or covers only very trivial tasks, isn't very useful. (Although in the latter case one can attain some insight by pondering why only such trivial tasks might be considered "lanugage agnostic".)
I'm not sure what any of these logical contortions have to do with SICP being 'language agnostic'. It isn't. The first section of the first chapter talks about why a Lisp dialect is used. This is the first figure.
