The current infra actually does something different – it is adding implicit statements, i.e. those still have a DeclaredStatement, but that declared statement shows up as being StatementOrigin.DECLARATION.

In the reactor this is implied by the use of SubstatementContext for these statements. In individual statements supports (which support this) it shows up as special-casing in createDeclared(). In yang-model-ri this manifests as ImplicitStatements – which end up recognized in factory methods and ignored.

This needs to work quite differently:

1. we need an optional-to-implement UndeclaredStatementFactory, which will have an alternative createEffective() method, which does rely on DeclaredStatement
2. we need an UndeclaredStmtCtx in the reactor, which will support Mutable.addEffectiveSubstatement(), with a better name of addUndeclaredSubstatement() – and there needs to be a checkArgument() to verify that the supplied support implements UndeclaredStatementFactory
3. ImplicitStatements needs to be removed (along with the classes it references)
4. We need to have an UndeclaredStatements to directly create EffectiveStatement instances
5. Users of ImplicitStatements need to be migrated to implement UndeclaredStatementFactory

The be-all end-all reason is that we do not have a reliable raw argument String, required for DeclaredStatements. The other is quick consistency checks to an opt-in behaviour – i.e. RpcStatementSupport can only use implicit input statements because InputStatementSupport knows how to deal with them – and that capability is not exposed as a trait (such as UndeclaredStatementFactory ), it is just an implementation detail. The third, minor one, is that we create bogus objects to dance around StatementContextBase's requirement of having a DeclaredStatement instance.

Okay, this is a bit more complicated and boils down to ModelStatement.statementOrigin() and its interpretation in DeclaredStatement vs EffectiveStatement. Part of this is an implementation quirk of statement loading, where we end up inserting UndeclaredCaseStatement into DeclaredChoiceStatement:

choice foo {
   case bar;
   container baz;
}

ends up looking like this:

ChoiceStatement foo
  DeclaredCaseStatement bar
  UndeclaredCaseStatement baz
    Container baz

The difference between Declared and Undeclared CaseStatements is only statementOrigin(). We have to account for this in yang-model-export and inline StatementOrigin.CONTEXT statements' substatements.

We therefore need to perform a bit of house cleaning:

1. eliminate generation of UndeclaredCaseStatement and instead inline Container baz, just as it is declared (YANGTOOLS-1383)
2. move ModelStatement.statementOrigin() to EffectiveStatement, eliminating Undeclared* DeclaredStatements (YANGTOOLS-1384)

Once that is done, we can roll out proper specialized implementations.