that included the same single inh entity more than once
(normally this should raise an error) could, in some cases
depending on what was being joined "from", implicitly alias the
second case of the single inh entity, producing
a query that "worked".   But as this implicit aliasing is not
intended in the case of single table inheritance, it didn't
really "work" fully and was very misleading, since it wouldn't
always appear.
fixes #3233

and :meth:`.Query.outerjoin` to a single-inheritance subclass
using ``of_type()`` would not render the "single table criteria" in
the ON clause if the ``from_joinpoint=True`` flag were set.
fixes #3232

- add support for self-referential foreign keys to move over as well when
the table name is changed.

of the "constants" :func:`.null`, :func:`.true`, and :func:`.false`
has been reverted.   These functions returning a "singleton" object
had the effect that different instances would be treated as the
same regardless of lexical use, which in particular would impact
the rendering of the columns clause of a SELECT statement.
fixes #3170

the given object if the object had been subject to a delete
operation that was flushed, but not committed.  This would also
affect related operations like :func:`.make_transient`.
fixes #3139

already have more than one ForeignKeyConstraint referring to them.
This limits the check to what we hope is the most common case,
but we benefit that the memory and config-time impact is scaled back
dramatically.

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