Will Tebbutt

@devmotion on second thought, I agree regarding the ICM, but I think our `IndependentMOKernel` is probably just not what we really want it to be -- I think it should...

Just for the record -- we should be using [ChainRulesCore](https://github.com/JuliaDiff/ChainRulesCore.jl) to define pullbacks for `Zygote`, and [ChainRulesTestUtils](https://github.com/JuliaDiff/ChainRulesTestUtils.jl) to test those implementations -- see e.g. [here](https://github.com/JuliaDiff/ChainRules.jl/blob/15add9bb1b4336ebf809354d04d515935f443b1c/test/rulesets/LinearAlgebra/dense.jl#L9) for example usage. Plans are...

😞

Thanks for opening this. In no particular order: - I'm not sure that I would put #98 under reworking the documentation, and it would be breaking if we modify that...

Great, in that case I'm pretty happy with it!

Could you make one of those milestone things with a link to each of the issue in? edit: it's called a project apparently.

I don't have any particular suggestion for a name here. `mul_approx` seems a bit too general to me, so I think that I prefer `mul_matched`.

> Actually your example proves the opposite for me as I would write the first option ~~So this actually isn't something that's safe to do in all cases. Consider~~ ```julia...

To be fair, in my previous example, I put it as one field. Upon reflection, I think it would be better in the SEKernel case to define it as ```julia...

> what should be dim(k) return? Well this would be an error on two counts -- `SEKernel(Euclidean(2))∘ SelectTransform((1, 3))` would error because the `SelectTransform` asks for the third dimension, but...