The problem is that non-conforming inheritance breaks the meaning that
'Current' had in the ancestor, because its type changes randomly. The
general pattern is

class SOME_CLASS
feature some_feature (arg: NON_CONFORMING_PARENT) is ...
end

class NON_CONFORMING_PARENT
feature
    s: SOME_CLASS

    anchor: like Current -- this will bring problems

    routine (arg: like Current) is
        do
            s.some_feature (Current) -- This just fine here
            s.some_feature (anchor) -- This just fine here
            s.some_feature (arg) -- This just fine here
        end
end

The class "NON_CONFORMING_PARENT" is well typed, according to the
classic (ETL2) language rules. Now let's introduce non-conforming
inheritance to the game:

class UNRECOGNIZED_SON
insert NON_CONFORMING_PARENT -- SE notation
-- inherit {NONE} NON_CONFORMING_PARENT -- ETL3 notation
end

Now the problem should be obvious. All the code from the parent
referring to Current, or anything anchored to Current, is now badly
typed. This is because, it breaks the normal Eiffel rule that made all
types of expressions go down (or stay at the same place) when
inheriting (i.e. covariance). When inheriting non-conformingly, the
type of Current doesn't go down, nor up, but changes randomly.

Is there anyone researching into this language design problem? Any
ideas about how to solve it without throwing NCI away (which, at a
glance, seems like a very useful tool)?

Before I finish this post, let me show you an extract coming from real
code:

class LINKED_LIST

inherit
    COLLECTION
        redefine copy end

feature
    from_collection (other: COLLECTION) is ...

    copy (other: like Current) is
        do
            from_collection (other) -- Correct here
            -- but incorrect in unrecognized children
        end
-- ...
end

The above code seems fine (and it is), but it makes impossible to
inherit non-conformingly from LINKED_LIST

Any ideas?