I expected the following

File
"test?somelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelon
gargumentlistsomelongargumentlistsomelongargumentlistsomelongarg"
will be created in current directory but it's not the case because filename is > 255 bytes.

If curl cannot create file because name is too long than I expect file with trimmed name to be created.

I agree with @jay. -O is about using the name from the URL as file name as that makes the client side absolutely sure what file name that will be used. Trimming it changes that and opens up a risk for overwriting files that were not meant to overwrite.

I'm using curl as a download tool for custom webkit-based browser (surf).

Option -J is necessary to have proper filenames for downloadable *zip, *pdf, etc. On the other hand I could trim filename by myself (in surf c code), but in such case I loose -J Content-Disposition filename because -o is apparently superior to -J.

So other expected solution would be:

curl -J -o "my-filename" "http://..."

but to make -o "my-filename" work only if Content-Disposition is not in the headers.

I think curl is doing the right thing here. It tries to use the name as instructed, and when it fails is tells the user why. With the landed fix, it should now display it even with very long file names in the message.