primaryjoin that referred to the same "local" column multiple
times in the "column that points to itself" style of self-referential
join would not be substituted in all cases.   The logic to determine
substitutions here has been reworked to be more open-ended.
fixes #3300

ultimately will populate a foreign key column in conflict with
another, where the relationships are attempting to copy values
from different source columns.  This occurs in the case where
composite foreign keys with overlapping columns are mapped to
relationships that each refer to a different referenced column.
A new documentation section illustrates the example as well as how
to overcome the issue by specifying "foreign" columns specifically
on a per-relationship basis.
fixes #3230

when we do a get; we return the None as always but we leave the dict blank
and the loader callable still in place.  The case for this implicit get on a pending object is not
super common and there really should be no change in state at all when this
operation proceeds.   This change is more dramatic as it reverses
a behavior SQLA has had since the first release.
fixes #3061

mapper is implicitly combining one of its column-based attributes
with that of the parent, where those columns normally don't necessarily
share the same value.  This is an extension of an existing check that
was added via :ticket:`1892`; however this new check emits only a
warning, instead of an exception, to allow for applications that may
be relying upon the existing behavior.
fixes #3042

a join condition that is strictly from a single column to itself,
translated through some kind of SQL function or expression.  This
is kind of experimental, but the first proof of concept is a
"materialized path" join condition where a path string is compared
to itself using "like".   The :meth:`.Operators.like` operator has
also been added to the list of valid operators to use in a primaryjoin
condition.  fixes #3029

flag allows a custom op from :meth:`.Operators.op` to be considered
as a "comparison" operator, thus usable for custom
:paramref:`.relationship.primaryjoin` conditions.

target of :paramref:`.relationship.secondary` for the purposes
of creating very complex :func:`.relationship` join conditions.
The change includes adjustments to query joining, joined eager loading
to not render a SELECT subquery, changes to lazy loading such that
the "secondary" target is properly included in the SELECT, and
changes to declarative to better support specification of a
join() object with classes as targets.

attribute history from being written on behalf of the target attribute.
This has the effect of the object not being written to the
Session.dirty list if it is mutated.  Previously, the object would
be present in Session.dirty, but no change would take place on behalf
of the modified attribute during flush.   The attribute still emits
events such as backref events and user-defined events and will still
receive mutations from backrefs. [ticket:2833]