choose function usage with rule inputs as parameters.

Don't use choose() at all now.  For anything.  We have a!match() now.

does it work with an array of values? I don't think so

If you're calling different sub-interfaces, then of course they'll need to be declared directly in the code for your parent interface.  I'm still a little shaky as to what your overall configuration looks like, but i'm guessing you can configure something along these lines:

a!match(
  value: local!selectedTabIndex,
  
  equals: 1,
  then: rule!BBB_TAG_1(...),
  
  equals: 2,
  then: rule!BBB_TAG_2(...),
  
  [... etc],
  
  default: rule!default_tab()  /* use for default or invalid selection, etc */
)

The issue is that the length should be dynamic, through parameters. The length of it can vary. But anyways, I am kinda pessimist about this being able to do that right now.

Silas. B. Ferreira said:

The issue is that the length should be dynamic, through parameters

How do you plan to handle a dynamic length of tabs with a prescribed set of sub-interfaces?  There isn't a way to dynamically generate (named) interfaces.

My component should be something like

{
  /* Example 1 */
  rule!App_TABS(
    tabs: { "TAB 1", "TAB 2", "TAB 3" },
    contents: {
      rule!APP_content_1(),
      rule!APP_content_2(),
      rule!APP_content_3()
    }
  ),
  
  /* Example 2 */
  rule!App_TABS(
    tabs: { "TAB 1", "TAB 2", "TAB 3", "TAB 4", "TAB 5" },
    contents: {
      rule!APP_content_1(),
      rule!APP_content_2(),
      rule!APP_content_3(),
      rule!APP_content_4(),
      rule!APP_content_5(),


    }
  )
}

The reason is that I want it to become an utility rule.

You need to figure out at most how many tabs can be there when either all conditions are passed or none applied.

If you can have at most 7 tabs then your match() needs to be configured with all 7 possibilities. Assign one unique index to each tab so that if dynamically only 4 tabs (e.g. Tabs 1,3,4 and 7) are selected, the indexes replicate the same.

If it easier you can also go with strings to match the selected tab with content instead of index. 

a!localVariables(
  local!selectedTab: "Tab2",
  a!match(
    value: local!selectedTab,
    equals: "Tab1",
    then: a!stampField(
      labelPosition: "COLLAPSED",
      icon: "angle-down",
      contentColor: "STANDARD"
    ),
    equals: "Tab2",
    then: a!stampField(
      labelPosition: "COLLAPSED",
      icon: "angle-up",
      contentColor: "STANDARD"
    ),
    equals: "Tab3",
    then: a!stampField(
      labelPosition: "COLLAPSED",
      icon: "angle-double-up",
      contentColor: "STANDARD",
      backgroundColor: "NEGATIVE"
    ),
    default: "No Priority"
  )
)

Just as you would need to manually create all rules rule!APP_content_X() for X = 1....n, you would need to hardcode them into your calling interface in some way or another.

a!match() provides far greater flexibility than choose() in that you don't strictly need an array of strictly n parameters passed into it, but can instead handle anything up to and including n.  But it doesn't, per se, buy you the ability to avoid hardcoding interface names that you need to call.

(But you might want to look at making all or some of these interfaces programmatic, meaning they share the same interface but act differently depending on a parameter you pass in - if possible, which of course I can't say for sure since I don't know how different they all need to be.)

The tab layout will remain the same, but the names and the contents will be different. I don't have the differences mapped, I am just just trying to make that possibility come true, so other mates can utilize for different contents and lengths as a component, that is it.

Either way you'll need to figure out a way to work within the system's constraints - mainly here that there isn't a supported way to call arbitrarily-named sub-interfaces (or other rules etc); whatever you want to use will need to be hardcoded into the parent interface.  You'll have a lot better time if you architect it in such a way that you can use a limited set of sub-interfaces and parameterize the contents using tab-specific data you pass in (as needed).

I appreciate that, but it doesn't meet my use case requirements for development utils.

I appreciate that, but it doesn't meet my use case requirements for development utils.