No action necessary, but now that custom ops have official support for views, I wonder if there's things we can do to make the inference mode handling smoother.

With this PR today, I guess wrapper subclasses still need special handling for inference mode for views (where ordinarily inference-ness being preserved via this line, but can be broken if the outer tensor must be rewrapped in a new subclass)

Do you have code sample that shows this concern?

Because LoggingTensor doesn't do this special inference-mode handling for views, doing

import torch
from torch.testing._internal.logging_tensor import LoggingTensor

base = LoggingTensor(torch.rand(1, 2, 3)).requires_grad_(True)

with torch.inference_mode(True):
    base.view(-1)

Fails with

Traceback (most recent call last):
  File "/Users/jw3468/local/.tests/tst1.py", line 9412, in <module>
    base.view(-1)
RuntimeError: Cannot set version_counter for inference tensor

Example of how it is handled in nested tensor:

def view_default(func, *args, **kwargs):
    ...
   with torch.inference_mode(inp.is_inference()):
        return NestedTensor(func(inp._values, inner_size), **extract_kwargs(inp))

This is unrelated to the change at hand so will move that to a follow up

If we're calling into the fallback now for the is_mutable case as well, being able to remove the whole branch would be a good simplification!
Is there something preventing us from doing that?

No we cannot :/
The inplace logic is based on user anotation and the schema is not actually made to reflect these inplace. So we do need this custom python logic to do the increment_version as the fallback won't do them.

We could refactor the whole thing to have accurate schema and rely on the fallback to do all incref though. But that is much more involved.

So is this literally just "remember all non-Tensor arguments, and then rerun the function if you need to reapply the view"?

Yes.
With extra complexity if there are tensor/symint other arguments, which I bypass