+There actually are now three different methods to access a child, allowing flexible and expressive integration:
+ * ``childByArg()``, which returns a child or ``null``,
+ * ``findChildByArg()``, which returns a ``Optional`` child,
+ * ``getChildByArg()``, which returns a child or throws VerifyException
+
+
+Another aspect that got attention is child ordering contract. Both ``MapNode`` and ``LeafSetNode`` are now
+specialized in disjunct interfaces based on how child iteration order affects semantics. ``SystemMapNode`` and
+``SystemLeafSetNode`` represent ``list`` and ``leaf-list`` constructs which have ``ordered-by system`` semantics --
+which is to say order of nodes is not part of semantics similar to what ``java.util.Set`` does. On the other hand
+we have ``UserMapNode`` and ``UserLeafSetNode`` for constructs which are ``ordered-by user`` -- hence the child
+iteration order is part of semantics, i.e. what ``java.util.List`` does.
+
+
+ModelStatement non-existent arguments
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The type mapping of YANG statements argument in the no-argument case has changed. These have been previously mapped
+to ``java.lang.Void`` to express non-presence. This mapping has caused nullability issues of ``ModelStatement.argument()``.
+These have been resolved through mapping non-existent arguments to ``org.opendaylight.yangtools.yang.common.Empty``,
+which maintains the same 'nothingness' contract through a singleton non-null object.
+
+
+XML namespace has a dedicated construct
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+In previous versions, we have used ``java.net.URI`` to model the argument of YANG ``namespace`` statement. This has
+proven to be a bit inefficient from both memory and CPU perspective, for example during looks. In this version, YANG
+namespace is represented by a dedicated ``org.opendaylight.yangtools.yang.common.XMLNamespace`` class. It performs
+same validation as ``URI.create()`` does, but it does not break the string into its constituents for storage like URI
+does.
+
+
+DataSchemaNode's `isConfigration()` is three-state
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The idea that a DataSchemaNode has a boolean attribute representing the effective value of ``config`` statement argument
+has been problematic due to its ignoring definition scope. As an example, ``leaf`` defined in a ``grouping`` has neither
+``config true`` nor ``config false`` effective statement.
+
+In order to fix this modeling problem, as well to stop users from attempting to perform various recovery strategies,
+a new method, ``DataSchemaNode.effectiveConfig()``, has been introduced. This method returns ``Optional<Boolean>``,
+accurately modeling the three possibilities. ``DataSchemaNode.isConfiguration()`` has also been deprecated for removal.
+
+
+SchemaContextUtil has been removed
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+A number of utilities dealing with SchemaNode traversal have been hosted in SchemaContextUtil. All of these were created
+with assumptions of ``SchemaPath`` and with the object model not understanding YANG XPath expressions. This has lead to
+some very obscure code with problematic edge cases.
+
+All of these utilities have been centralized in a stateful SchemaInferenceStack. This stack encapsulates state related to
+how a piece of logic has come to know about an EffectiveStatement. There are number of simple operations, such as
+``enterDataTree(QName)``, ``enterGrouping(QName)``, ``exit()`` and similar.
+
+The stack also provides faculties to resolve ``type leafref`` path expressions, adjusting its internal state to provide
+a path from the conceptual schema root to the leaf a particular leafref (indirectly) points to.
+
+State of a SchemaInferenceStack can be converted to an immutable ``EffectiveStatementInference`` instance. This construct
+serves as the modern replacement of ``SchemaPath``. Rather than containing an opaque path, though, it contains a sequence
+of statements and attached semantics. This allows us to accurately address statements and communicate the state of the
+SchemaInferenceStack across API boundaries, as a SchemaInferenceStack can readily be reconstituted from a number of different
+EffectiveStatementInferences.
+
+A number of entry-points, most notably to XML and JSON codecs, now take an ``EffectiveStatementInference`` instead of
+a ``SchemaPath`` or a context ``SchemaNode``. For migration purposes, users having these available can use the following
+snippet to migrate:
+
+ .. code-block:: java
+
+ EffectiveModelContext context = ...;
+ SchemaNode node = ...;
+ EffectiveStatementInference inference = SchemaInferenceStack.ofSchemaPath(context, node.getPath()).toInference();
+
+
+Unrecognized YANG statement handling
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+YANG parser's does not reflect unrecognized YANG language extensions, defined by
+an ``extension`` statement, in the effective model as exposed by EffectiveModelContext.
+
+This has a direct impact on the contents of ``DocumentedNode.getUnknownSchemaNodes()``, as unrecognized extensions
+will not be presented in the list.
+
+Unrecognized extensions are those that are defined by an ``extension`` statement, but do not have a corresponding
+YANG parser handler. These extensions cannot be semantically be bound and the YANG parser handles in accordance with
+`RFC6020 <https://datatracker.ietf.org/doc/html/rfc6020#section-6.3.1>`__ by treating them as unsupported extensions.