When your window control closes, focus returns to the element that invoked the window unless it is very unlikely users need to immediately reinvoke the window.

We use your window control as a popup search dialog. Our customers search for their data there, close the popup and then return to a dialog with lots of input fields.
The user had previously focused on one of these input fields and would like to have the focus back in this input field after closing the popup.
Which has worked wonderfully up to and including your version 8.0.0.

Unfortunately, this no longer works since version 8.1.0 and instead of the input field, only the button that previously opened the popup is focused. This change from the changelog seems to be responsible for this: "window: update focus management and kb navigation to match the ARIA spec".
It seems that your change uses a setTimeout internally, which keeps taking the focus away from our input field.

You can reproduce this behavior in a demo application. The first application is based on version 8.3.0 and you can reproduce the problem there by pressing the button and closing the opened popup. The focus that was previously in the input field is then on the button. Here: https://stackblitz.com/edit/react-xdpeqc-nycw86?file=app%2Fapp.tsx,package.json
In the second application based on version 8.0.0, you can see that the same process sets the focus directly back to the input field. Here: https://stackblitz.com/edit/react-xdpeqc-yab7m8?file=package.json,app%2Fapp.tsx

Nowhere in the ARIA specification here does it say that you should use a setTimeout to steal the user's focus again at a later time in order to set it on the button that opened the popup. On the contrary, point 2.1 describes exactly what we need:

You already had this feature in version 8.0.0 and could offer it again as a property with very little implementation effort. Please consider to add this old behaviour as a Window Prop again.

If the zoom property is set on the body element for a preset zoom your window control does not seem to correctly take this zoom into account for the position and width/height of the window. You can easily recreate this in the following example application: https://stackblitz.com/edit/react-qmwfbf-fzmj98?file=app%2Fapp.tsx,index.html

Simply open the window using the button and then maximize the window in the title bar at the top. You can see that the width/height calculation is much too large and is not correctly maximized to the available space. You can also see this in the attached video.

A similar problem has already been reported here for popups https://github.com/telerik/kendo-react/issues/2320 and there is also a solution for this using the scale property in the PopupProps here:

<PopupPropsContext.Provider
      value={(props) => ({
        ...props,
        scale: 1.25,
      })}
    >

Please add exactly the same scale property for the WindowProps. 

Setting the stage prop to "DEFAULT" does not update the Window component as expected:

const [stage, setStage] = React.useState<string>('DEFAULT');  

const handleStageChange = (e: WindowActionsEvent) => {
    setStage('DEFAULT');
  };

<Window
          stage={stage}
          onStageChange={handleStageChange}

Setting the window position is not permanent.

How to reproduce:

1. open https://stackblitz.com/edit/react-hyhjxg?file=app%2Fapp.tsx
2. click 'move to corner' button
3. click the window title bar
4. the window changes its position to the previous one, but it should remain in place.

Chaging window stage also reverts previous position