Does anyone working at Github know why 'semi-linear' merge isn't supported as a merge strategy in the merge queue (and regular PRs)?

I Gitlab and Azure DevOps (also owned by MS) supports it, and even talked to an employee now working at Github, that implemented this in Azure DevOps.

More background: https://github.com/orgs/community/discussions/14863

With a semi-linear merge strategy, you rebase (without --fast-forward) before merging, so the history ends up looking like this:

    *   c8be0c632 Merge pull request #1538 from my-org/api-error-logging
    |\  
    | * 80ecc4985 Fix security warning, bump nokogiri
    | * 750613638 Log and respond with more detailed validation errors in the API
    | * 0165d6812 Log code and details when rendering an API error response.
    | * 1d4daab48 Refactor email validation result to include a descriptive message
    | * 635214092 Move media_type logging into context_logging
    |/  
    *   1cccd4412 Merge pull request #1539 from my-org/profile-clarify
    |\  
    | * 87b342a32 Rename profile default to migration target
    | * 2515c1e59 Fix disallow removing last profile in company
    |/  
    *   b8f3f1658 Merge pull request #1540 from my-org/customer
    |\  
    | * 064b31232 Add customer-specific taxed allowance reduction
    |/  
    *   3cf449f94 Merge pull request #1528 from my-org/console-logging
    |\  
    | * 99657f212 Don't log to rails console in production
    |/  
    *   8c72e7f19 Merge pull request #1527 from my-org/gemfile

It makes it easy to look at the Git history both at the 'PR level' kind of like a change log (`git log --merges --decorate --oneline`) or dig down into each PR to see all commits.