The first check was introduced to fix the issue reported in bug #44501.

in file.c there is a double check for stream locking support, but the first check is done in the worong way. 
i'm not a c programmer, i think that should be done somethink like this

if(file_lock) then
   if(is_stream && !stream_support_locking) then
     throw error
   endif
endif

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The stream_support_locking() merely checks if stream->fd is present, it does not 
"actually" check if locking is supported. Therefor the check is actually correct.

This is extracted from standard/file.c starting from line 618.

I have commented some fundamental parts for this bug.

...
} else if (flags & LOCK_EX) { // exclusive lock?
  // the following lines does not check any real stream locking support
  // this code will block all protocols 
  // that use LOCK_EX, except file://


  // are we using a stream protocol? eg: file:// http:// custom://
  if (php_memnstr(filename, "://", sizeof("://") - 1, filename + filename_len)) {


    // if the protocol is not  file:// throw an error
    if (strncasecmp(filename, "file://", sizeof("file://") - 1)) { 
      php_error_docref(NULL TSRMLS_CC, E_WARNING, 
          "Exclusive locks may only be set for regular files");
      RETURN_FALSE;
    }

  }
  mode[0] = 'c';
}

// the following lines can not be reached by any other 
//protocol using LOCK_EX, except file://
mode[2] = '\0';

stream = php_stream_open_wrapper_ex(filename, mode, ((flags & PHP_FILE_USE_INCLUDE_PATH) ? USE_PATH : 0) | ENFORCE_SAFE_MODE | REPORT_ERRORS, NULL, context);
if (stream == NULL) {
  RETURN_FALSE;
}

// better locking check
if (flags & LOCK_EX && (!php_stream_supports_lock(stream) || php_stream_lock(stream, LOCK_EX))) { 
  php_stream_close(stream);
  php_error_docref(NULL TSRMLS_CC, E_WARNING, "Exclusive locks are not supported for this stream");
  RETURN_FALSE;
}

  

According to current implementation of file_put_contents there is no way to use exclusive locks support with a custom protocol wrapper.

I have just been bitten by this issue, and for all I can tell the reasoning 
behind what goetas writes makes me think "yeah, right!".

Could someone *please* reevaluate the "not a bug" statements?

+1!
i'm right with you!