if this is just for testing purposes, then probably data-testid.

Yeah, IDs are mainly supposed to be used for associating HTML elements with other elements, or associating elements with browser URL state

I want to say that if you need some kind of "ID-like value"/testing hook for your elements, and the value doesn't have any functionality for the end-user, data attributes (like data-testid) are the way to go

Another concern is that HTML IDs have to be globally unique. If multiple HTML elements have the same ID, that can cause some nasty jank (e.g., clicking a form input, and a different input getting highlighted)

React has a built-in hook for making it easy to have unique IDs, even when you're working with reusable components
https://react.dev/reference/react/useId

Regardless of the main way we end up selecting the element, I would recommend making sure the selector asserts that the element we're grabbing is actually exposed to the user as a button (ideally through something like page.getByRole)

It's possible to add click behavior to non-button elements, but that can get janky quick. Changing the selector would add an extra security net to ensure that users can use all the behavior that buttons bake in automatically

I think that with the new parameter, the function is getting a little unwieldy, and if you're looking at things from the consumer side, it's hard to tell which of the five arguments correspond to what

Maybe this could be refactored to an object, so that we have sort of have named arguments?

type CreateWorkspaceInputs = Readonly<{
  // Required properties
  page: Page;
  templateName: string;
  
  // Optional properties
  richParameters?: readonly RichParameter[];
  buildParameters?: readonly WorkspaceBuildParameter[];
  externalAuthProvider?: string;
}>

I agree in principle, but I think 5 params is still manageable and not worth refactoring the 26 usages of this function IMHO. Happy to discuss.