Should having a concrete private member which does not implement the super interface signature(s) be a static error?

This [issue](https://github.com/dart-lang/sdk/issues/47923) points out a discrepancy in the static errors emitted by the CFE and the analyzer. The question raised is relevant to the question of how to deal with [field promotion](https://github.com/dart-lang/language/issues/2020) as well.

I filed an [issue](https://github.com/dart-lang/language/issues/2263) to explore the question of whether to require the existence of a combined member signature for inaccessible members, which is relevant to the resolution of this issue as well.

Consider the following program:

```dart
//lib.dart
class A {
void _m(int i) {}
}

abstract class B implements A {
void _m(num n);
}
```

```dart
// example.dart
import "lib.dart";

class C extends A implements B {}

void main() => C();
```

This code is currently accepted by the analyzer, and rejected by the CFE. Per @eernstg , section 10.2.2 (Forced by Privacy) applies here, and a noSuchMethod forwarder should be generated, and per the same section, it is not an error for the noSuchMethod forwarder to override a concrete method (as it otherwise would be).

Notably, it is **not** specified (as best I can tell) what the signature of that noSuchMethod forwarder should be. Depending on the resolution of #2263 that may be obvious (the combined member signature) or not at all obvious. Per current spec, I believe there is not necessarily a well-defined choice, since we do not require a combined member signature to exist.

TODO: @eernstg somewhere in the spec we must specify the check which enforces that in a *concrete* class, the inherited members satisfy their interfaces also doesn't apply for inaccessible members, right? Since we don't require that for abstract classes, e.g. we could could `B` extend `A` above and nothing would change here. Presumably this also filters by accessibility?

The question for this issue is whether we should continue to make an exception to the rule against overriding concrete methods with noSuchMethod forwarders for the case of inaccessible members.

For the purposes of #2020 we would of course have to insist that any such forward always throw.

It seems surprising to me, and not especially helpful, that an instance of `A` can exist for which calling `_m` does not reach the implementation specified in `A`. This seems contrary to the idea of library privacy.

cc @eernstg @lrhn @munificent @jakemac53 @natebosch @chloestefantsova @johnniwinther @scheglov

Start with the examples in lib.dart and example.dart, then read issue 47923, field-promotion issue 2020, and language issue 2263 alongside specification section 10.2.2. Resolve the behavior for inaccessible concrete members and noSuchMethod forwarders, including their signature and static-error rules; done requires an agreed language-specification change.

Written by the indexing model from the issue text.