We can look into that a bit more easily if we rename the struct fields (so the field type doesn't clash with the symbol type)

funcs.explode("types").rename({"type":"symbol"}).with_columns(pl.col("types").struct.rename_fields(["field_type","named_field"])).unnest("types")

If we look at the values, they're basically one-to-one between the unpacked field key-value pair's key name (i.e. the field name of the symbol), with some exceptions, e.g.:

• function_item "body" symbol type doesn't exactly match the field type ("block") but same idea - this is the bit with the main function content in
• function_item "name" has 2 fields ("identifier" and "metavariable")
• there are optional parts like return_type nd type_parameters (required = false)
  • the return_type is present in all 3 of the symbols: function_item, function_signature_item, and function_type

There is obviously more here.

In terms of reliable targets I would expect that fields with required: true would be useful because we could always find them if we are looking at some semantic object (e.g. here the block field in the body key

We would then be able to write a program to conditionally extend our match range to the other, optional, parts of the AST based on a check for them in the surrounding nodes

Looking more closely at that function_item

funcs_types = funcs.explode("types").rename({"type":"symbol"}).with_columns(pl.col("types").struct.rename_fields(["field_type","named_field"])).unnest("types")

funcs_types.rename({"multiple":"_multiple","required":"_required"}).filter(pl.col("symbol") == "function_item").unnest("children")
funcs_types.rename({"multiple":"_multiple","required":"_required"}).filter(pl.col("symbol") == "function_item").unnest("children").explode("types")
funcs_types.rename({"multiple":"_multiple","required":"_required"}).filter(pl.col("symbol") == "function_item").unnest("children").explode("types").unnest("types")