> In my experience, Page Objects sound neat in theory but end up as a leaky abstraction: they mix UI details with test logic, duplicate flows,

You might be asking too much of them to the point they become a burden.

1. Page Object Model should not contain any test-related stuff. It should abstract common page interactions:

  registerUser({ email: string, password: string, displayName: string })

  findProduct(name: string)

  addProductToCart(id: string, quantity: number)

etc

Then what you do in your tests is:

  registerUser("abc@foo.net", "passw0rd", "foo name")
  login("abc@foo.net", "passw0rd")'
  // now you test
  expect(page).findByText("Welcome back foo name").toBeVisible()

> and make even trivial UI changes ripple through dozens of files.

2. Given my previous example, if you changed the login or registration form you'd only update the implementation of `registerUser`.

In any case I also want to emphasize: POMs are very useful when collecting and reusing the data (e.g. in the previous example `login()` would take no params and reuse those declared before), you can achieve 95% of their functionality with plain simple helper functions.