I believe the cipher names should be separated by colon (when OpenSSL is used).

In your first use case shown above, you separate them with space without quotes, which makes curl treat the second cipher name as a URL.

Yet locating each ciphers between ' ' ' or ' " ' while keeping spaces lead to the same result.

You'll have to use a colon to separate OpenSSL ciphers, @bagder has fixed the doc to clarify this.
--ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384
sends these in the ClientHello:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

In the doc it says if this option is used several times the last one will be used and that means for example
--ciphers ECDHE-RSA-AES128-GCM-SHA256 --ciphers ECDHE-RSA-AES256-GCM-SHA384
sent in ClientHello:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

I realise that I did not interpret the post illustrated by the link 835a2fe as a comment. In that context I kept searching an unofficial way to make the function perform as desired. One pertinent result I got at last: when specifying multiple cipher names under a same ciphers option (--ciphers), separating them with comma (,) was validated by curl function.

Since there is two approaches involving the use of multiple ciphers within a same curl function, and one was documented –the one involving multiple '--ciphers' options–, then approach involving multiple cipher names specified under a same ciphers option (--ciphers) does obviously remain unknown.

In that last approach, illustrated here by the command curl --ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384, does the order according to which ciphers are arranged matter? What does this means both from a user and server perceptive?

separating them with comma (,) was validated by curl function

curl just accepts whatever string you tell it, and it will pass it on to the TLS library. You can separate them in however way you want and curl won't complain. As long as they're passed as a single string.

Since there is two approaches involving the use of multiple ciphers within a same curl function

I don't think there is.

one involving multiple '--ciphers' options

That just makes the second use override the previous one, that's not really multiple ciphers.

does the order according to which ciphers are arranged matter?

The OpenSSL document says the string is an "ordered SSL cipher preference list", which makes me suspect that the order is the preference.

The OpenSSL document says the string is an "ordered SSL cipher preference list", which makes me suspect that the order is the preference.

Wireshark dumps confirm this.

Time will come also for me to use_Wireshark_, since needed addition of a dnscrypt dissector is to come. You had right intuition regarding SSL ciphers preference order. Yet what could be the use-case that would justify the last option to override the previous ones regarding a command involving multiple ciphers options? I could not seasonably conceive any appropriate use-case by myself.

scripting, make your last setting for an option override any previous one. like for example if you set a $CURL variable to use some common options like curl --ciphers foo and then in your script you have $CURL --ciphers bar, or in your curlrc you have --ciphers foo and on the command line you use --ciphers bar in either case bar overrides foo.

If you're using Wireshark you can use SSLKEYLOGFILE environment variable which curl 7.56.0+ w/OpenSSL 1.0.2+ supports and then you see the decrypted transfer.

Environment variable performed as intended, I was not able to achieve a relevant test command using curl, here curl --request POST https://www.startpage.com/do/search --data 'linux curl' that behaves the way URL https://www.startpage.com/do/search, –here written using POST as HTTP method – involving search terms 'linux' 'curl' would in a web browser.

So I finally used that command which is also involved in the following snapshots :

curl --http2 --ciphers ECDHE-RSA-AES256-GCM-SHA384 -OLX POST https://getfedora.org/static/checksums/Fedora-Server-29_Beta-1.5-x86_64-CHECKSUM

Outputs bring to my knowledge:

• client supported ciphers suites. Probably Curl will support TLS 1.3 cipher suites too when that version becomes to be widely used by servers.
• No compression method supported neither by client nor by server.

Indeed Client'Hello's generated random numbers for the master key are forwarded to specified file:

Surprisingly the server does not pick up from client's available ciphers option 0xc030 despite Qualys SSL Labs informed it to be supported.

That ClientHello does not look as it should if you are using curl with OpenSSL. Turn on verbose mode -v and check that the cipher selection is set:

* Cipher selection: ECDHE-RSA-AES256-GCM-SHA384

If you don't see that line it's possible you are using curl with an SSL backend that doesn't support cipher selection or requires a different format.

Different issue:

Probably Curl will support TLS 1.3 cipher suites too when that version becomes to be widely used by servers.

You can set TLS 1.3 ciphers by using option --tls13-ciphers since 7.61.0. I will clarify this in the CIPHERS doc.

Using curl --ciphers ECDHE-RSA-AES256-GCM-SHA384 -OLX POST (...), I got now server to pick up the set cipher:

(...)
* Cipher selection: ECDHE-RSA-AES256-GCM-SHA384
(...)
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
(...)
* Using HTTP2, server supports multi-use
(...)
> POST /static/checksums/Fedora-Server-29_Beta-1.5-x86_64-CHECKSUM HTTP/2
> Host: getfedora.org
> User-Agent: curl/7.61.1
(...)

Might it be a way to get a list of cipher suites supported by server using the v option in curl command ? For instance regarding a cipher suite using Chacha –0x1303– which is supported by client curl and supported by OpenSSL, using TLS13-CHACHA20-POLY1305-SHA256 in curl command.