This isn't at all how the other classes you referenced behave. What's the use case for having a property vs. clients just not using the wrapper if this is the behavior they want?

I'm using floating_material_search_bar which always has a widget filling the whole screen for hit testing. I need the widget to pass through touches to a Google Map when the search bar is not focused, but intercept them when the search bar is focused.

I didn't look at the implementation of Ignore/AbsorbPointer, but how is this different than how they behave?

AbsorbPointer documentation:

When [absorbing] is true, this widget prevents its subtree from receiving pointer events by terminating hit testing at itself.

IgnorePointer documentation:

When [ignoring] is true, this widget (and its subtree) is invisible to hit testing.

PointerInterceptor(
  intercepting: intercepting,
  child: const Text(''),
);

Is a lot simpler than:

Builder(
  builder: (context) {
    if (intercepting) {
      return const PointerInterceptor(
        child: Text(''),
      );
    } else {
      return const Text('');
    }
  },
);

I used mobile.dart as reference for what to do when the flag is false.

I didn't look at the implementation of Ignore/AbsorbPointer, but how is this different than how they behave?

They don't conditionally change what build returns, unless I missed something.

[...]
Is a lot simpler than:
[...]

That's true, but that's a false choice because you're duplicating the code to create the child. If what you want is to conditionally wrap something in a PointerInterceptor you could make a trivial local helper method that does that.

On implementation

There's two ways to do this. One is what this PR does or the helper method that @stuartmorgan is suggecting (let's call it "conditional build"). Another one is to do it at the RenderObject level (let's call it "conditional render"). There are pros and cons.

Pros of conditional build:

• If the value of intercepting doesn't change over time (or changes rarely), then it's more efficient for the false case because it doesn't increase the size of the Element tree.
• Simple implementation (as this PR shows)

Pros of conditional render:

• More efficient if the value of intercepting changes frequently. Because pointer interceptor is a platform view it alwaysNeedsCompositing, so it will break up pictures into more layers than when there's no interceptor. If the widget flips between intercepting and not, it will significantly alter the shape of the render tree and especially of the layer tree. At the render object level the tree could be kept more stable between intercepting or not because it could keep the same layer structure.

Conditional rendering would have to be implemented in this package. Conditional build can be implemented as a helper function.

On ergonomics

I really prefer the ergonomics of a flag compared to having to write a helper function. You won't have many interceptors in the same library, but you may have many interceptors across your codebase and the discovery of a custom helper function like this will be low. In most cases we want people to just be able to import this package and get good ergonomics from it out of the box. If enabling/disabling the interceptor is an important use-case, then I'd argue it should also be ergonomic out of the box. Honestly, I wouldn't want to write that if/else even once. If the interceptor is in the middle of a deep widget hierarchy, making it conditional will mess up all of the surrounding code.