The useFocusRing hook has an option of isTextInput which from my understanding when false, a focus ring will be shown an input element with any interaction. When set to true this will change behaviour so the focus ring is only shown on keyboard interactions.

Not quite, setting isTextInput to false makes it so that we bypass this part of the code and use the current user modality as the way to determine if a focus ring should be shown. This still means only keyboard and virtual modalities will show a focus ring (aka clicking on a button/input won't display the focus ring since that is pointer modality). This behavior is the same in 3.14.3: https://codesandbox.io/p/sandbox/infallible-panna-forked-ddzqcm?file=%2Fpackage.json%3A11%2C33, clicking in the input field doesn't cause the focus ring to appear.

However, prior to this change: #5359, a input element that used useFocusRing and had isTextInput=false would render a focus ring if the user clicked into the field and then typed within it. However, we only want to show a focus ring when tabbing into or hitting Escape when within a input field, hence the addition of the automatic input element detection in that PR.

Thank you. Seems like a misunderstanding on my part of what exactly the prop did.

Is this documented anywhere? The description of "Whether the element is a text input" doesn't explain much.

Thank you for clearing it up.

Presumably if I wanted to maintain a focus ring for all interactiona including pointer, then I will need to use a traditional CSS pseduo selector?

This isn't explicitly documented anyway, we can certainly look to make the props description better or even deprecate it since we do automatic detection now perhaps.

Presumably if I wanted to maintain a focus ring for all interactiona including pointer, then I will need to use a traditional CSS pseduo selector?

Yep, that's correct