In the attached video I am showing the steps taken to reproduce the bug from the reproduction link. Basically if you change the year in DatePicker's calendar - no matter which year you select - the year gets reset back to 1911. I was not able to reproduce this in Kendo's CodeSandbox examples until I noticed that they were using the legacy ReactDOM.render() instead of the new React 18's createRoot. As soon as I replaced it I was able to reproduce the bug.
Another strange observation is that I am able to reproduce this bug in only half of my tries after refresh, another colleague reproduces it in 20-25% of his tries, so it doesn't happen all the time but eventually it will. That's why I've recorded a video on a fresh reload of the attached reproduction. Also, you can sometimes see the year is already wrong after selecting it, or after subsequently selecting the month, or sometimes you don't see the year is reset to 1911 until after you select the specific date and the popup closes.
Although there are other ways to reproduce this issue, the one shown in the video is the easiest to hit the bad scenario. Also, we were not able to reproduce the issue on the DateTimePicker, although it seems to use the same Calendar component underneath.
Our assumptions having previously reported similar problems in Kendo after migrating to React 18 is that due to the concurrent rendering / batching of state updates in React 18's createRoot - something breaks the virtual scroll used in the calendar (in the video when I point to 1912 being the next year after the selected 2021, if we scroll a bit, the virtual scroll picks up and updates the incorrect years) so we end up with stale data for the year when selecting the month/date. This means that there might be other unwanted side effects that we just haven't stumbled upon.
This is a severe bug for our application's end users as they are unable to change the year in the date picker reliably. Falling back to the deprecated ReactDOM.render is not an option.