I have to agree. It does make the docs somewhat awkward, but I'm not sure there's a better solution, given the circumstances.
On the plus side, I applaud the compile-time-checkability of approximating overloaded function args by implementing an interface trait for various tuples.
(My main interest in Rust is as a maximally compile-time checked replacement for Python in the creation of I/O-bound applications... within the limitations imposed by "Not Haskell. It's too hard for me to reason about performance characteristics and/or memory footprint in a lazy, GCed, pure-functional language.")
I'm not the type to depend on alpha libraries (I have enough trouble finding time to maintain projects written against mature ones) but, once this has matured a bit, I definitely foresee myself using it to replace the approach I'm currently migrating to. (Write/rewrite as much of the backend as possible in Rust, expose a Python API using rust-cpython, and write/keep the frontend in PyQt.)
EDIT: One thing I do like about your decision to use traits to approximate function overloading is that, because you used public traits, libraries which depend on these bindings can implement them to get a function overloading analogue to Deref coercion.