DWORD maps to uint, see https://learn.microsoft.com/dotnet/standard/native-interop/best-practices.
HWND maps to UIntPtr, and nuint is a new better alias for UIntPrt.

This is really not my field.. Are you sure about HWND mapping to UIntPtr and not IntPtr? https://learn.microsoft.com/en-us/windows/apps/develop/ui-input/retrieve-hwnd

Yes, I'm sure. The link that I shared contains all the relevant information:

I believe this table should not be read in rows, there are two columns of related types and not a mapping between column A and column B. And HWND is listed in a column which has IntPtr in the header.

Yes, you're right. I'm having a brainfart moment....
HWND == IntPtr == nint.

GetComboBoxInfo should probably accept a pointer instead of a ref too....

    NativeMethods.COMBOBOXINFO* tConfig = new();
    tConfig->cbSize = sizeof(NativeMethods.COMBOBOXINFO);

There are examples in dotnet/winforms codebase in release/6.0 or release/7.0 (before they moved to CsWin32 definitions - something we should probably do too...).

sizeof(COMBOBOXINFO); won't do

I've proceeded with calculating it once and then
cboInfo.cbSize = NativeMethods.COMBOBOXINFO.SizeOf;

I'm sorry but "should probably accept a pointer" part is way over my head, I have not seen it done that way. Also there are several interop methods accepting ref params. I feel being pushed to do something new and which was not done in GE before instead of continuing in the steps of patterns that are already present.
Usually "stylistic" changes, or changes in approach are done in a sweeping "lets change all the places at once" manner. Sorry if I am misunderstanding something.

sizeof(COMBOBOXINFO); won't do

I've proceeded with calculating it once and then cboInfo.cbSize = NativeMethods.COMBOBOXINFO.SizeOf;

The screenshot contains the answer as well. The method must be marked as unsafe.

I'm sorry but "should probably accept a pointer" part is way over my head, I have not seen it done that way. Also there are several interop methods accepting ref params. I feel being pushed to do something new and which was not done in GE before instead of continuing in the steps of patterns that are already present. Usually "stylistic" changes, or changes in approach are done in a sweeping "lets change all the places at once" manner. Sorry if I am misunderstanding something.

Using blittable types (i.e., those that map directly from the managed to the unmanaged memory) and the unsafe code gains perf. Some of our interop definitions are old and, thus, carry perf overhead.

    [StructLayout(LayoutKind.Sequential)]
    internal struct COMBOBOXINFO
    {
        public uint cbSize;
        public RECT rcItem;
        public RECT rcButton;
        public ComboBoxButtonState buttonState;
        public nint hwndCombo;
        public nint hwndEdit;
        public nint hwndList;
    }

    internal enum ComboBoxButtonState : uint
    {
        STATE_SYSTEM_NONE = 0,
        STATE_SYSTEM_INVISIBLE = 0x00008000,
        STATE_SYSTEM_PRESSED = 0x00000008
    }

    [DllImport("user32.dll")]
    internal static extern BOOL GetComboBoxInfo(nint hWnd, COMBOBOXINFO* pcbi);


    private static unsafe int CalculateVerticalScrollBarWidth(ComboBox comboBox)
    {
        NativeMethods.COMBOBOXINFO cboInfo = new()
        {
            cbSize = (uint)sizeof(NativeMethods.COMBOBOXINFO)
        };

        fixed (NativeMethods.COMBOBOXINFO* pcboInfo = cboInfo)
        {
            if (!NativeMethods.GetComboBoxInfo(comboBox.Handle, &pcboInfo))
            {
                return 0;
            }
        }

        // ...
    }

I couldn't get it working with the fixed block, please help :)
See Interop adjustments based on PR review commit

We are updating all callsites. Any reason not to update the implementation to scale the passed arguments?

While it would be more convenient and produce less diffs I think that semantically this is correct - this is a straightforward utility method and the caller has control and responsibility to understand what is being done. Unless we'd add ResizeDropDownWidthDpiAware..
Anyhow, I see your point. I personally would lean towards semantic correctness (which I guess could also be debated :) ) and leave it the way it is at the same time this is not the hill I'm ready to die on so if you'll tell me to change this, I will.

Can you think of a scenario where we'd want to resize a dropdown without scaling for the current dpi? If not, then I can't see any reason why we shouldn't be doing scaling implicitly - i.e., not rely on a caller to remember to scale before resizing.

One scenario came up, it's when you want to adjust the width based on some other control width which is already scaled. You'd need to de-scale it which is not pretty. I solved it by introducing an optional parameter bool dpiScaleBounds = true and this one place which didn't require scaling sets it to false

I don't believe this is a correct import. On 64-bit systems, it should be GetWindowLongPtrW:
https://github.com/dotnet/winforms/blob/698cfb403515150b08ca8cd1f201b5d0aacde813/src/System.Windows.Forms.Primitives/src/Interop/User32/Interop.GetWindowLong.cs#L11-L26

Is it possible to reuse the other API to avoid code duplication?

This works because toolStripComboBox.DropDownWidth = 123 actually redirects the setting of DropDownWidth to underlying wrapped (ComboBox)comboBox.Control.
Updated.