> Is this change compelling enough to break compatibility,
> or is it just a matter of purity?

I agree with Antoine that making this change is a really bad idea.

1) The current behavior has been around for a long time and is implemented in several modules including decimal and fractions.   As core devs, we need to keep focused on a priority of making the language stable (not making changes that truly necessary and invalidating all previously published material) and more importantly not adding yet more obstacles to converting from Python 2 to Python 3 (which Guido has called "death by a thousand cuts").

2) The current behavior can be useful it that it allows floor division operations without unexpected type conversions occurring in the middle of an expression.  We really don't want to break those use cases.

# Here is a simple example of a chain of calculations 
# where preserving the type matters

from __future__ import print_function
from fractions import Fraction
from decimal import Decimal

def f(x, y):
    return x // 3 * 5 / 7 + y

def g(x, y):
    return int(x // 3) * 5 / 7 + y

for x, y in [
        (Fraction(85, 7), Fraction(2, 3)),
        (Decimal('12.143'), Decimal('0.667')),
        (12.143, 0.667),
    ]:
    print(f(x, y), g(x, y))

In Python 2:
------------
8/3 8/3
3.524142857142857142857142857 2.667
3.52414285714 2.667

In Python 3:
------------
3.5238095238095237 3.5238095238095237
Traceback (most recent call last):
  ...
    return int(x // 3) * 5 / 7 + y
TypeError: unsupported operand type(s) for +: 'float' and 'decimal.Decimal'


I am a strong -1 against breaking code that relies on the floor division being type preserving.

The PEP should be revised to say that floor division is defined to return a value that is *equal* to an Integral but not place any restriction on the return type.