Technically, it builds, but in a way that's not useful. It would actually be
better if it had failed (I noticed this from reviewing build logs after the
python3 interpreter depends weren't generated correctly).
In fact, the package works fine on python3.5 as well as python3.6 (the module imports, and the full test suite passes against the installed modules), thus I'm downgrading the severity of this bug.
During the build, the extension modules are first built on python3.5, and it is these modules that land in /usr/lib/python3, with the "abi3" ABI tag. The extension modules are then built again on python3.6, but these don't get moved into /usr/lib/python3 due to the files from the python3.5 build having the same name, thus landing in an incorrect directory in the final package and serving no useful purpose.
The reason the package still works is the "abi3" ABI tag; these modules (like all CFFI-built modules, by default) are using the Python 3 "stable ABI"[1] so the modules built on python3.5 work fine when imported on python3.6, and vice-versa. I think what this means is that we only need to run the Python 3 build once (using the default version?); also, I think the interpreter depends are in fact correct in light of this. I tested downgrading to 1.7.1-3 and the module still imports and works on python3.6, even though 1.7.1-3 was only ever built against python3.5.
However, testing against all supported versions at build time is probably still appropriate.
I'm looping in debian-python here as others may be surprised by this combination of effects as well, and we should probably be handling the issue of modules using the stable ABI consistently. Also, I'm not 100% certain what the best way forward is here; teach pybuild/dh_python3 about the stable ABI?