While not answering your questions directly...
I totally understand, your examples are artificially, but I would like to advice you to drop the OO-style of solving problems because I think the problems you're trying to solve are originating from "OO tactics".
My suggestion is to use traits like some sort of "last resort" and first look out for solutions using concrete types.
For the printing example, instead struct PrintScheduler accepting trait Printable it should accept something like a struct PrintJob or whatever: a concrete type, maybe even a POD like data, or a Vec with print commands etc.
Then printing clients provide methods like print_document(&self) -> PrintJob, and print_overview(&self) -> PrintJob etc.
For testing, you can simple check the generated PrintJob of some clients match your expectation.
Same thing for the PrintScheduler. It accepts PrintJob as inputs and generates some output, whatever the role of the concrete PrintScheduler is. The generated output of processed PrintJobs are also checked against your expectation etc.
In summary: pass around concrete data: a call-site ask object A to generate some data (struct), takes this data and feeds this data into object B. That's how things fits nice together. There is no need, that A implements some interface (trait) that B uses to call back on A.
Shuffle concrete data around, and things become simple(r).