It looks like it should be

Quickly glancing at the implementation I believe the idea is that because we know 'range' exists we should only add "multi" to know the actual length after replacement. I agree the other side - where 'range' is not present - has a bug, it should not sum the count with "multi" but "_multirange" as you say. That seems like a careless copy paste on my part. Could you add that fix to the PR?

str = str.Slice(0, NAMEDATALEN - "multi".Length);
is
str = str.Slice(0, 58);
and that is the final name. PG just trims it to 63 after doing the replace.

Right, that slice bound should be adjusted, as you concluded correctly 'multirange' is already present in the final string.

Something like this?

// Static transform as defined by https://www.postgresql.org/docs/current/sql-createtype.html#SQL-CREATETYPE-RANGE
// Manual testing on PG confirmed it's only the first occurence of 'range' that gets replaced.
public DataTypeName ToDefaultMultirangeName()
{
    var nameSpan = UnqualifiedNameSpan;
    if (nameSpan.IndexOf("multirange".AsSpan(), StringComparison.Ordinal) != -1)
        return this;

    var rangeIndex = nameSpan.IndexOf("range", StringComparison.Ordinal);
    if (rangeIndex != -1)
    {
        nameSpan = string.Concat(nameSpan.Slice(0, rangeIndex), "multirange", nameSpan.Slice(rangeIndex + "range".Length));
        if (nameSpan.Length > NAMEDATALEN)
            nameSpan = nameSpan.Slice(0, NAMEDATALEN);

        return new(string.Concat(Schema, ".", nameSpan));
    }

    if (nameSpan.Length > NAMEDATALEN - "_multirange".Length)
        nameSpan = nameSpan.Slice(0, NAMEDATALEN - "_multirange".Length);

    return new(string.Concat(Schema, ".", nameSpan, "_multirange"));
}

The "range" -> "multirange" replace result will still need to be limited to NAMEDATALEN characters

Edited, it's ok to merge it into this PR.

We will only be able to use the AsSpan if the length is equal or greater than NAMEDATALEN. How does the last commit look?

Ahaha well that serves me, trying to do this off the cuff from github.

@NinoFloris Added a few tests. That turned up another bug in FromDisplayName where !displayNameSpan.Slice(schemaEndIndex).StartsWith("_".AsSpan(), StringComparison.Ordinal) was never false. Changed the code to match its intention but I can't say if its correct or not to ignore qualified arrays.

Right, the comment is essentially referring to the following strange case in PG:

SELECT 'pg_catalog._int4'::regtype, 'pg_catalog.int4[]'::regtype;

both resolve successfully and return the display name integer[]

I will take another look, apologies for the delay, I even had a pending review from earlier. Don't hesitate to ping me. I sometimes just need to be reminded again.