Can you provide an example as well? I finally parsed why we would want this from the original issue, and I think it’d be a helpful example to have.

I guess I’m also still concerned that@efiring issue with the locator being different is still valid because the locator also returns the autolims. Which locator wins if the locators are different? This should be consistent and documented.

Given the warning of possible dire consequences, why do this at all? I think this is simply a bad idea, short of a total overhaul of the way we track and determine axis limits.

I think it’s a useful idea to have a second scale for the same axis, which i think was the original idea. But I’m not at all sure this is the best way to do it.

My personal example, is I have a timeseries data, on two shared x-axis. I want to put timestamps on one of the axis labels, but want to format the second axis labels a different way (but still have them linked, so when I drag or zoom one the other drags/zooms too).

I don't think this is a bad idea at all in theory - the location of data on the graph is independent of the ticks and labels above. I'll have a proper look at the autoscaling worries soon.

(at least as a minimum being able to set different formatters would be good if setting different locators is a problem.)

To record my findings, the way I thinkautoscale_view works is:

1. Callautoscale_view on a single axis (I don't think it's possible to call it on a shared set)
2. Work out the data limits from all the current axis and all of its shared axis'
3. Using these data limts, let the locator of thecurrent axis determine the final view limits

So I don't think having different locators is a problem code wise - there might just be different results depending on which axis is autoscaled, even if they are twinned. Would that be a problem?

This and#10961 are almost the same thing....

Okay, I'll close this in favour of discussion on#10976, thanks for taking the time to look over this!