1. NORMAL. Some operators draw a dotted line, that gets disconnected from the pointer when the stylus is repositioned. Affected operators: Rotate, Scale, Bevel, Edge Crease, Edge Bevel Weight, Inset Faces, Bevel Vertices, Bend, Image editor/Movie Clip Editor > Mask Mode > Mask > Scale Feather. Dope Sheet > Slide (Shift+T) also draws a line, that may be disconnected form the pointer. But that line doesn't make much sense anyway. Same deal with the Scale operator here. Note that some operators do not show the dotted line if called from the top menu. Use hotkeys or the viewport menus (like Ctrl+E for View3D Edge menu). I haven't looked at the code, so I don't know if there's a common implementation of the dotted line. But as the operator list may be not exhaustive, it's much preferable to have a general solution for all the cases.
2. LOW. Sometimes continuous grab continues when the tablet cursor goes outside the window bounds, sometimes it stops at the window edge. Apparently it always stops at the edge if WinInk is selected. In case of WinTab, the grab will continue if there was a tap inside the window client area after the window received focus. If there was no tap after the widow received focus, or the window title was tapped, then the grab will stop at the window edge.
3. LOW. In case "Use Windows Ink" is unchecked in the Wacom settings, and "Windows Ink" is selected in Blender input settings, the walk-navigation view rotation does jump when repositioning the pen.
4. NORMAL. Snapping: After the pen is repositioned, the visual point that snaps to the target is lost (the cursor is no longer at that point). It still snaps when the previous cursor position is connected with the target, but there's no visual cue to where that point is.
5. LOW. Movie Clip Editor > Tracking > Clip > Track > Add Marker: The marker doesn't stick to the cursor (after the pen repositioning). With a tablet it's probably natural to expect being able to click on a feature to place a marker. Dragging the marker like it is right now is tolerable, but not exactly a tablet way.
6. NORMAL. It is possible to break some operators like Rotate by making the dotted line too long or too short, compared to the actual distance to the pointer:
7. LOW. Walk nav is affected by "Continuous Drag" setting. Steps: Disable "Continuous Drag" in the preferences (why would someone do that?). Result: unable to rotate 360 degrees using a mouse, tablet jumps on repositioning in walk nav. In 2.93 walk nav is unaffected by this setting.
8. LOW. View rotation may get stuck with Click & Tap pen mode. Steps: Switch the pen click mode to "Click & Tap" in the tablet preferences (Hover Click / Click & Tap), push MMB on the pen, press the pen, start dragging, release MMB while dragging, lift the pen (do it all quickly). Occasional result: The view gets stuck in the rotation mode. Tapping/lifting the pen, clicking the mmb or switching windows don't quit the view rotation mode. The only way to get it unstuck is to press ESC, or to MMB+tap the pen. Alternative steps: Make Blender window not maximized, start mmb+tap-dragging, drag outside the Blender window, alt+tab to some other window, lift the pen and release the mmb, switch back to the Blender window - the view rotation is now stuck.

Can't test:

• VR. https://docs.blender.org/manual/en/dev/addons/3d_view/vr_scene_inspection.html , https://www.marui-plugin.com/blender-xr/ , https://devtalk.blender.org/t/ubisoft-animation-studio-vr-development-discussion/13123 .
• Whether there are any affected addons.
• Platforms other than Win10 and different tablets.
• Fancy setups with HIDPI monitors and different scaling (not sure if it matters).
• Battle test in production.

@Vincent Blankfield (vvv) Thanks for checking on this.

1. Any other operators with similar "draw toward the cursor" UI I should look into? What's happening here is that the operator infers the real cursor location from the accumulated location and knowing the wrap bounds, I'd suspect this shows up in more places.
2. is just differences in WinInk/Wintab and how the fallback for broken Wintab drivers works.
3. is not surprising, I'll investigate it a bit more to see if there's a solution but I suspect not.

If you have some more time (or already checked) I'm also curious if any issues came up with multi-window scenarios.

I will occasionally poke random areas of Blender with my pen, and update my previous comment if I find something. I'm not a real QA and don't know Blender very well, so the process may be slow and results unreliable. I've got to note that this change (global continuous grab) has quite a scope. In particular, some addons may be affected.

In D12408#323374, @Vincent Blankfield (vvv) wrote:

I'm not a real QA and don't know Blender very well, so the process may be slow and results unreliable. I've got to note that this change (global continuous grab) has quite a scope. In particular, some addons may be affected.

Your QA is great. Already it's made clear to me that the scope of this task is larger than I had assumed. :)

I think this warrants a separate task to track operators affected by changes to continuous grab. Also this may be a Blender 3.1 target as we're 2 weeks out until bcon2.

At this point I'm done with testing this manually as a black box. If I get curious and have nothing to do sometime in the future, I may also take a look into the code. But for now the list of issues in my first comment may be considered complete. I went trough pretty much all of the GUI-accessible operators and every mode of every editor. Even if I missed something, it probably can be dealt with later, when it is found. Torturing this patch with different tablet settings, window switching, other unexpected actions mid-operation yielded nothing (except Windows, driver or other unrelated bugs).

Given that the tablet walk nav is broken in master and 9.93.5rc, and this patch may be postponed till 3.1, should we at least apply a temporary fix? Like something I've proposed previously. It had the scope strictly limited to the walk operator, so even if there are problems with it, it shouldn't be a big deal. It can't make tablet walk nav more broken than it is anyway. The problem with that is I don't know if Blender policies allow applying such temporary hacks. I hope the proper fix can make it in time though.