Actually Style.t is used for everything, so a viewStyle is a t, and array(...) is t too, same for arrayOption. This means if we change style props from Style.t to array(Style.t), you could still use array and arrayOption.
Like said above, this is due to the fact that RN accepts nested arrays, so you can pass in JS style={[[{color: "blue"}], [[{"backgroundColor": "red"}]]]} and it will work.

Exactly. Otherwise we would have already run into trouble seeing how helper functions allow recasting array(Style.t) into Style.t.

I like this change, but I further propose defining Style.style to return array<t> instead of t as below. Then, minimal refactoring would needed and we can still continue writing style=someStyle. The resulting type definitions would not be less precise in practice either.

style: (
  ~resizeMode: resizeMode=?,
  ...
  ~zIndex: int=?,
  unit,
) => array<t> = ""

Oh that is actually an interesting idea but maybe that would allow people to write things that will create runtime error like someStyle->Array.length ?!

That's a valid concern. Multiple styles would become a worse problem with this too. Joining an actual array and an element would be problematic.

I suppose I haven't thought this through.

Yes this would not be safe

I'm still thinking style should accept an array directly

On my project:

944 usages of style={

• 395 x Style.array
• 64 x Style.arrayOption

Like @MoOx said, there is too much dynamic styles on a mobile today: light and dark mode, safe area insets, screen dimensions, ios vs android vs web, …

Yeah I just remember I read something about it, but it say

accessing the returned style objects at runtime is still not recommended as it can prevent static extraction to CSS

so my point about using spread operator is still irrelevant.