Yes. To enable proper keyboard navigation (and fix keyboard traps for users with accessibility needs) changes were made to the kyeboard interaction model in 4.1. These are documented in this section of Extension Migration Guide which I recommend as the first place to consult if something is not working in your extension after upgrading (or when testing pre-releases).
Biefly, since Fix tab trap notebook cells by gabalafou · Pull Request #14115 · jupyterlab/jupyterlab · GitHub the keydown event is no longer caught in the capture phase but in the bubling phase, and the focus in the command mode no longer reverts back to notebook container node (which beside loosing tab index position was also causing random scrolling for some users).
This means that to in order for shortcuts to be active in command mode, we need to specifically exclude the input nodes. This was initially achieved with :focus:not(:read-write) selector but it proved problematic in Panel widgets which used shadow DOM (Typing into into fields that are wrapped with shadow DOM is intercepted by commands · Issue #15757 · jupyterlab/jupyterlab · GitHub), thus a new .jp-mod-readWrite class was added in Fix typing in editable elements inside of open shadow DOM by krassowski · Pull Request #15774 · jupyterlab/jupyterlab · GitHub which peeks into the shadow DOM too.
This is now all documented in Keyboard interaction model section of the JupyterLab notebook docs. It appears that your widget is not detected by the negative selector, possibly because it does not use a native input element, or is not marked as content editable (etc).
We have panel widgets that take data input (looking like a data grid)
How do you implement these widgets? If this is with custom key even handlers, adding a lm-suppress-shortcuts class to the widget container (see the Keyboard interaction model link above) may be a simple solution for you.