Neither a feature or a bug.
These are just different ways of abstraction, each of which can be preferrable
in some situation. I like concepts (that is, implicit ones, as they are) too,
I'd not want them just to be replaced with interfaces (explicit concepts), the
proposition is of having both ways. The purpose of interfaces is to express
programmer's intention; not what concepts are intented to.
About Go's interfaces: I don't know this language, I just heard that something
very different is called by interfaces in it, just sharing the same word;
probably it's something nearer to concepts; better not to compare things as
respective just because of wording, this is why I've mentioned explicitly
Delphi (Object Pascal), Java, PHP and C# (probably there are more) as having
this feature.
Still there is some difference between interfaces in those languages and
explicit concepts, as proposed for Nim: those are based on dynamic dispatch;
this not what really needed, procs can be instantiated statically per concrete
type, the same as with implicit concepts (as now). So they are still the same
concepts in all respects, except:
* they don't match types, which were not declared explicitly as satisfying
these explicit concepts;
* obviously, there is a way to declare for a type, that it satisfies some
explicit concept, like proposed `satisfies MyConceptName` in type declaration,
or it can be `implements`, or a pragma (`{.satisfies: MyConceptName.}`);
* obviously, some addition in concepts syntax, to mark it as explicit: again,
proposed `explicit` before `concept` keyword, or a separate keyword
`interface`, or a pragma (`type X = concept {.explicit.}`).
