headers and tls should not be forced named arguments to keep the signature similar to the existing methods with form: being the only difference.
I would also add notes to the docs of the methods which accept IO and String that using form is exactly the same as body + Content-Type header.

@straight-shoota No. If headers is not a required named argument it becomes very confusing in my opinion. I don't want to change it.

In fact I would probably go the other way and make headers be a required named arguments for the non-form versions. Since an http request can specify body and headers but both of these are optional, relying on argument order is bad and bug-prone.

Actually, I'll try to change it if possible, there's probably no confusion because the types are different.

I'm not sure what would be confusing about having optional (named or positional) arguments together with a required named argument.

But at least I'd find it confusing if headers and tls in one variant of the same method can be optional positional arguments, in the other variant they need to be named arguments.

So it should be either optional positional or optional named-only arguments everywhere. I'd stick to the existing signatures because there is little benefit from having them named-only.

I agree that we should make headers etc. be required named arguments in a later pr.

Why later?

I'm actually not sure that headers must be required. It was a rushed reply of mine 😊

It shouldn't be required to be present, it should be required to be a named argument, not a positional one.