Java arrays pose several challenges for records, and these added a number of constraints to the design. Arrays are mutable, and their equality semantics (inherited from Object) is by identity, not contents.

The basic problem with your example is that you wish that equals() on arrays meant content equality, not reference equality. The (default) semantics for equals() for records is based on equality of the components; in your example, the two Foo records containing distinct arrays are different, and the record is behaving correctly. The problem is you just wish the equality comparison were different.

That said, you can declare a record with the semantics you want, it just takes more work, and you may feel like is is too much work. Here's a record that does what you want:

record Foo(String[] ss) {
    Foo { ss = ss.clone(); }
    String[] ss() { return ss.clone(); }
    public boolean equals(Object o) { 
        return o instanceof Foo f && Arrays.equals(f.ss, ss);
    }
    public int hashCode() { return Objects.hash(Arrays.hashCode(ss)); }
}

What this does is a defensive copy on the way in (in the constructor) and on the way out (in the accessor), as well as adjusting the equality semantics to use the contents of the array. This supports the invariant, required in the superclass java.lang.Record, that "taking apart a record into its components, and reconstructing the components into a new record, yields an equal record."

You might well say "but that's too much work, I wanted to use records so I didn't have to type all that stuff." But, records are not primarily a syntactic tool (though they are syntactically more pleasant), they are a semantic tool: records are nominal tuples. Most of the time, the compact syntax also yields the desired semantics, but if you want different semantics, you have to do some extra work.

I highly recommend Project Lombok (site here https://projectlombok.org/). From the example you listed

 public record Person(String name, String gender, int age) {}

That can be done via Lombok like this

import lombok.Data

@Data
public class Person {
    private String name;
    private String gender;
    private int age;
}

Lombox creates getters and setters, toString, hashCode, and a default constructor, as well as one with all the orgs.

UPDATE: It was pointed out in the comments that records are immutable. You can easily achieve this with lombok in a couple of ways. Option 1:

import lombok.Data

@Data
public class Person {
    private final String name;
    private final String gender;
    private final int age;
}

That will add, again, the required-args constructor. @Data does not, for relatively obvious reasons, create setters for final fields.

Option 2 is a little more explicit:

import lombok.*;

@RequiredArgsConstructor
@EqualsAndHashCode
@Getter
public class Person {
    private String name;
    private String gender;
    private int age;
}

With Java 14, records couldn't have multiple constructors (reference: Java 14 - JEP 359: Records (Preview)).

As of Java 15 and 16+, records may have multiple constructors. (see Java 15 - JEP 384: Records (Second Preview) and Java 16 - JEP 395: Records (Final)).

However, every constructor must delegate to the record's canonical constructor which can be explicitly defined or auto-generated.

An example:

public record Person(
    String firstName,
    String lastName
) {
    // Compact canonical constructor:
    public Person {
        // Validations only; fields are assigned automatically.
        Objects.requireNonNull(firstName);
        Objects.requireNonNull(lastName);

        // An explicit fields assignment, like
        //   this.firstName = firstName;
        // would be a syntax error in compact-form canonical constructor
    }

    public Person(String lastName) {
        // Additional constructors MUST delegate to the canonical constructor,
        // either directly:
        this("John", lastName);
    }

    public Person() {
        // ... or indirectly:
        this("Doe");
    }
}

Another example:

public record Person(
    String firstName,
    String lastName
) {
    // Canonical constructor isn't defined in code, 
    // so it is generated implicitly by the compiler.

    public Person(String lastName) {
        // Additional constructors still MUST delegate to the canonical constructor!
        // This works: 
        this("John", lastName);

        // (Re-)Assigning fields here directly would be a compiler error:
        // this.lastName = lastName; // ERROR: Variable 'lastName' might already have been assigned to
    }

    public Person() {
        // Delegates to Person(String), which in turn delegates to the canonical constructor: 
        this("Doe");
    }
}