In general, this makes sense to me.

Is there anything that would speak against making VectorTransform public? That would allow to directly let users know what to use in lieu of the deprecated "data" argument, without the need to reinterate the complete thing in case someone does have a custom use case of it.

I would strongly doubt that there are many users of offset_position="data". But if you're worried about this we can replace the Deprecation by a PendingDeprecation, as usual. (On the other hand, seeing whether we get complaints or not is also one of the points of the deprecation period.)
At least I haven't fully thought about what the public API re: VectorTransform should be, and I would perhaps like to use something similar to replace some of the annotation coord strings (cf discussion at #13515).

Even if the amount of users hit by this isn't massive, it's still not the right policy to first break something and then wait if someone complains. Often enough, people might just be frustrated without opening an issue about it. In this case I think that the functionality of an offset transform in data coordinates is in general useful. I would agree that this does not require an additional argument, but should be incorporated into the transform itself. So removing offset_position in the long run makes sense. But if no alternative can be provided by now, the whole thing can be postponed up to when a general concept for such offset transforms is developed.

The changelog entry can mention e.g. "if you need this functionality, you can vendor the implementation of _VectorTransform" (which is quite short if you don't bother with __str__) "Please let us know if that's the case; then we will consider making this a public API". (If one is really using offset_transform="data", that's a fairly low level thing and vendoring the transform code is really not that hard once you already have to update the call sites anyways.)

I simply disagree that we can never deprecate things on the basis that someone may possibly be using them; as always there is a cost-benefit ratio that needs to be considered, and certainly if someone actually complains about it we'll consider it more.

(Some notes mostly to self: there's already transforms.offset_copy and text.OffsetFrom on the same theme.)

@anntzer If I understand correctly, hexbin could be implemented without offset_position or the new _VectorTransform. Would such an implementation be inferior? Slower, for example?
The transforms machinery has always been hard to understand, visualize, and remember, at least for me, and it would be good if any changes that are made serve to make it a little less difficult, a little more readable. The name _VectorTransform is not helping.

The problem is that without _VectorTransform (I'm not particularly in love with the name), collections (or more specifically, _CollectionWithSizes, which PolyCollection (the class returned by hexbin()) inherits) will by default size their components (the hexagons, in this case) to have a size in physical units (points), whereas we want to have them in data units, which is what _VectorTransform achieves. (Previously, this had to be built in to every renderer class, _VectorTransform just factors out that functionality.)

We could instead use PatchCollection, which just takes a bunch of patches and plots them as is (see e.g. the very recent thread on the mailing list https://mail.python.org/pipermail/matplotlib-users/2019-May/001663.html); however such an approach would at least lead to more inefficient vector output because the vector file would need to include every hexagon on every point, rather than a single hexagon and encode a list of offsets. In fact, this is the very reason why offset_position exists (#859); that PR indicates that just dropping the amount of data sent from python to agg also significantly accelerates agg.

Pushing out to 3.3 as I think this needs to be understood a bit better still.

It also looks like we currently have the ability to cycle through data transfroms (?!) and there is no documented path for a user who was directly creating the collection and passing data to adjust their code.

I would like to reiterate the possibility to make _VectorTransform public. There has just been #16548, where of course one could draw circles in data coordinates, but in addition to the options shown in the SO post OP linked to, probably the fastest option would be to use a PathCollection.

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.collections as mcoll
import matplotlib.transforms as mtrans
import matplotlib.markers as mmarkers

c = mcoll.PathCollection(
                [mmarkers.MarkerStyle("o").get_path()],
                offsets=np.repeat(np.arange(10),2).reshape(10,2),
                edgecolors=["k"]*10,
                transOffset=mtrans.IdentityTransform(),
                offset_position="data")
plt.gca().add_collection(c)
plt.gca().set(xlim=(-2, 11), ylim=(-2,11))
plt.gca().set_aspect("equal")
plt.show()

That option is gone if offset_position="data" is deprecated without replacement.

OK, I made VectorTransform public, but marked it as experimental to allow for later changes depending on actual use..

Ignore/WithoutOffset seems to hide the relevant semantics to me and focus more on how they are achieved

Can you paraphrase that semantics (maybe even directly in the docstring)? I think I probably haven't fully understood offset_position='data' and VectorTransform, but maybe that's also the point. The current docstring just says

A transform wrapper that ignores the offset component of a base transform.

And that's what I've been trying to pick up for the name. That description and the name VectorTransform do not make a connection in my head.

Edited the docstring, does this look better?

Thanks, the extended description looks good. I still feel a mismatch between the class name and the summary line. IMHO they should be on the same level of abstraction. So either

class VectorTransform(Affine2DBase):
    """
    A transform for connection vectors between points.

    This wraps another transform and ignores its offset component.
    ....

or

class IgnoreOffsetTransfrom(Affine2DBase):
    """
    A transform wrapper that ignores the offset component of a base transform.
    ....

I think that, more precisely, the vectors you think of are direction vectors (in contrast to position vectors). Maybe DirectionVectorTransform is a suitable alternative name?

Ah, I see the confusion now. Yes, I meant https://en.wikipedia.org/wiki/Displacement_(geometry), not https://en.wikipedia.org/wiki/Position_(geometry).

Pushed a new version.

DifferenceTransform? DeltaTransform? SizeAndShapeTransform? I'm struggling. It would really be nice to have a name that would be highly evocative--which for me, VectorTransform still is not. It seems that the zeroing of the offset really is the key to understanding what the wrapper is doing. So I tend to favor ZeroOffsetTransform, or NoOffsetTransform, or something like that. Or, if you want to include the mathematical property, it would be DistributiveTransform, since it is modifying a transform to make it distributive with respect to addition.

DisplacementTransform? OffsetTransform?
Or we can just poll this over the call :)

Let‘s briefly discuss in the call.

I don't believe this came up in any call; I've put it on the agenda for next week (though we might not get to it.)

On call we settled on AffineDeltaTransfrom for name.

renamed

done, as "position deltas".

rebased

Travis reporting seems broken; there are not currently any builds running.