I wouldn't say "can't use curl" (otherwise you'd also need to say that wget etc doesn't work which we don't know) but rather say something positive like "use netcat if you want to control the API manually via CLI"

Is this because curl is based on wget? Has anyone ever used curl in this scenario?

I think I once tried curl, but as you found out it's the wrong tool (you might be able to work around it by misusing http headers which I didn't try). Curl and wget are both standard tools for issuing web (HTTP) requests and I often use them interchangeably.

#1975 is the initial PR which already lists nc. I agree that a quick and dirty start guide is missing.

I'd suggest not to even mention curl or wget as this would just cause confusion. Direct the user to the correct tool right away.

I also tried curl, as did others. Standard tools seem uniquely qualified for explicit guidance when they aren't fit. And if wget is less clear, we needn't mention it. I haven't seen confusion around it, anyway.

Can we link to #1975 from here? It even has a code snippet. "See this page for connection examples using nc and Node.js."

I'd rather include the code snippet here.
Maybe even add a shell example with authentication.

Or we could see this as the start to write an actual JSON-RPC page on the website?

If a squash becomes required, I'm not into it. So now I'm reluctant to add commits, because the wrong one can trigger a squash request, and stall the work. Would it be controversial to merge this now, and perhaps do more later? I bet that's unrealistic too, due to translation?

The app isn't a problem at all concerning the translation. If you're really that reluctant of squashing, one of the maintainers can do it. We try to merge every PR with at least one (better two) reviews which means that contributors might need to add commits. The last step is a rebase and squash.

Would it be controversial to merge this now, and perhaps do more later?

I will figure squash out, but it's just part of my problem. Writing docs professionally has made me opinionated about workflows. In the workplace, sometimes I will say, "We might do more later. But can this be merged?" It's a way to ask if an acceptability bar has been met. It can circumvent apparent disagreement about the ideal options. I caused some guy to flip out when I asked this once. He had (unrealistic) demands and I wasn't dancing like a monkey for him. But a simple yes/no was appropriate! There can be perfectionism in the engineering mindset.

What are the implications of adequate but non-ideal documentation changes? The same content might involve multiple PR's, which probably implies more commits. I suppose it results in a publication that could include sub-optimal tips. Adequate but not optimal. Any other concerns?

Finally, have you used the Add a suggestion interface? Give it a try here if you can. I guess it would generate a commit that might need squashing. But there's something about the "documentation philosophy" discourses that make me itch, and maybe they wouldn't if we all tried writing our ideal improvement, rather than writing about it.