* I'm working on using embedded-hal-compat for transitioning a side-project form e-h 0.2 to 1.0. It uses the i2c mux driver [xca9548a](https://crates.io/crates/xca9548a) which implements blocking `Write`, `Read`, `WriteRead` but no iterator or transaction traits. The current i2c forwarding is implemented only for an implementation of all i2c traits and `WriteIter`, `Transactional`, ... aren't by xca9548a.

I can easily solve the issue for xca9548a by [adding markers and implementing partial forwarding](https://github.com/sirhcel/embedded-hal-compat/commit/7a08849c1d758353c9affe696c54dec1401dfa3c). But this forces to use explicitly selecting the type of forwarding/the actual marker for all i2c implementing more than `Read` and `Write` like

```rust
use embedded_hal_compat::{Forward, ForwardCompat};
use embedded_hal_compat::markers::ForwardWriteReadWritereadI2c;

let mux = Xca9548a::new(shared_i2c.acquire_i2c(), SlaveAddr::default());
let ports = mux.split();
let fw_port0: Forward<_, ForwardWriteReadWritereadI2c> = ports.port0.forward();
```

which looks like a pretty annoying change for all such implementations.

Moving from `ForwardCompat<T, M>` to a custom forwarding trait for i2c could solve this by only pulling the forwarding trait for your implementation in question into scope. But this would be also a breaking change.

Negative trait bounds could solve this elegantly at a first glance. But this is fairy dust which is not available.

Any ideas how to overcome explicitly specifying the marker for forwarding with the right set of implemented i2c traits and breaking the current interface for i2c forwarding?