This is probably not obvious but the reason we wrote our own test recorder is not to be playwrite - there are many great options for that. Rather we did it to get a feature that no off the shelf test recording framework can provide - recording to test shims that increase test stability / resiliency release to release.
The issue with basically all off the shelf UX test recording tools is they have to get a handle on parts of your ui and will generate the best pointer to ui elements that they can figure out and then directly interact with them like a user (lets click on that thing). That pointer if you are lucky in web is an id=“” element but its often a long xpath match. So what happens is you upgrade the software and ui elements are moved or changed somehow and your tests break and need to be updated to function again. With large volumes of tests this becomes a huge problem.
Many years ago as we built our ux platform we included a test shim framework so that we could build stable automated tests - basically there is a shim to talk to for every component with simple methods to update the data, activate it, find it by its stable id, etc and if we update the component to be structured differently we update the shim so it still works the same way in test. Our test recorder writes tests that instrument that, and that lets us have to fix dramatically less tests up each release. That’s really the point of it - and it’ll evolve more rich ui that is more similar to off the shelf tools over time.