[Dlang-internal] Is there any chance to introduce concepts/traits/typeClasses in dlang?

[sighoya]

I know there is already a package available from atila neves 
about concepts, but despite being a neat workaround, it delivers 
not the full opportunities we know from type classes.

Why?
TypeClasses aren't a static solution only, they can also be used 
as existentials allowing dynamic dispatch implying that you can 
change the underlying implementation at runtime:
function(Concept c):Concept{...}

Further, implementing concepts over inner fields is limited, 
usually assoc functions are used (UFCS in case of D) which may 
can be covered with the concepts package of atila over dlang's 
compiletime reflection library "traits".
However, how instance resolution works then? Functions associated 
to types are local only, so if we import the concept from another 
module how can we check satisfyability if the needed 
ufcs/associated functions aren't imported likewise to the concept?

I know, introducing a new entity to existing entities like 
interfaces unnecessarily increases the complexity but how about 
reusing existing interfaces for that purpose?

For instance:

interface A
{
void method1();
}

interface B
{
void method2();
}

class C implements A //structural implements (valid D)
{
void method1() {...}
}

implement B for C //implement is a block keyword like class for 
posthoc implementation
{
method2(){...}
}

Another solution would be a pseudoclass:

class D implements B for C
{
method2(){...}
}

Now passing a C to B requires not only too look for C's 
definition but also for instances either globally in the project 
(preferred) or with special import for instances.

Another point to consider struct implementations via autoboxing, 
is it that hard to implement?
Also allowing fields in interfaces would complete the usefulness 
of concepts.

A possible look how flexible it can be taken from the nim language
Link:
https://nim-lang.org/docs/manual_experimental.html#concepts

I donna want to rant about D, I love it, really. But introducing 
classes separate to interfaces irks me and was in my eyes a 
failure from Java and all languages which follow them.

Why?
Because it introduces a biworld, both concepts overlap and you 
have to decide which to choose which is further complicated by 
availability of abstract classes, so why not unify all of them 
into a single concept?
Class methods were always default methods akin to default methods 
in interfaces and