Google Go, OOP, Interfaces and Inheritance

It seems these days new programming languages and in particular "systems" programming languages aiming to replace C/C++ are sprouting like mushrooms. I like programming languages therefore for me this is fun, the general public however usually is utterly unaware of these small languages, at least until they become old and somewhat established.
Last week however a new language was presented by nobody different than Google itself. Accordingly it made quite a splash. After everybody had cooled down a bit it turned out that this new language - Go - was mostly quite unremarkable. It consists mainly of a non-daring combination of tried and true language features each of which has been around for quite a while, put together with a strong focus on the simple and non-fancy.
It seems the only feature that received a bit of lasting attention is the lack of classical OOP. Although dissing OOP is sort of a trend at the moment, presenting a new supposedly mainstream language without classes and inheritance still attracts attention.
Instead of inheritance Go promotes composition. Polymorphism is achieved by a very simple mechanism - instead of letting classes declare the conformance to an interface at the time of the declaration of a class, every type that has the right combination of methods associated with it automatically conforms to an interface.
This last feature is it that the designers of Go (and quite a few other people) seem to be most excited about.
The funny thing is - this has been one of my pet peeves for ages and is actually quite an old hat. When I started to learn C++ (coming from Objective C) one of the things that bugged me most was that which interface a class implemented (or abstract base class it derived from in C++ terminology) was practically part of its implementation details. The feeling that this was a bad idea became even stronger when I later on learned Java. There is all this nice polymorphism and reflection but if you just quickly want to make a new interface for an existing class you have to jump through all sorts of hoops.
Then I found out that gcc had this nice C++ extension called 'signatures' which worked more or less exactly like Go's interfaces. At the time when I discovered them the documentation still bravely stated that signatures were being considered as an official part of the language. As we all know, this never happened so I didn't use them (as far as I know nobody did) and instead toyed with the idea of autogenerating some kind of template-based interface-adaptor.
It turned out that I wasn't the first to do so. A language called Heron was based on the same idea and even implemented as a front end to C++. It seems the author however lost interest at some point and abandoned the language.
Further there is the greatly underappreciated and sadly abandoned language Sather which separated inheritance and polymorphism as well.
Obviously not a new idea, thus, but unfortunately one that never took. A while ago I even proposed the same feature for the D language on their mailing list - of course unsuccesfully, the feature was too alien, my explanation too bad and my reputation too non-existent.
At some point my frustration with the rigidity of OOP (and many, many other things) in C++ became so big that I did what everybody seems to do - I started working on my own programming language. Separation of code reuse and polymorphism are one of its key features (the scope of the project long since snowballed from a modest redesign of C++ to a complete start from scratch, but that's a different story).
Accordingly it gives me a bit of a stale feeling to see everybody getting all excited about this supposedly revolutionary and brilliant feature. On the other hand having the momentum of Google behind it will hopefully finally give the idea enough exposure to find out whether it is indeed a viable alternative to classical OOP.