I think it's only a documentation problem which should explains which are the allowed characters in the salt (from code: a-z A-Z 0-9 . /)

(notice: It is strongly recommended that you do not generate your own salt for this function)

Would it be worth then having an error or a boolean/null return value rather than 
have it "fail" silently? If at any point the allowed characters for the salt were 
to extend then past hashes (where a salt was generated by the developer with 
previously invalid characters) would be broken.

If you give the developer the option to provide a value then surely it should be 
either accepted or denied rather than just ignored.

This is not a bug. This is as designed.

The reason is that crypt requires a salt that's base64 encoded. A space 
character is not a valid character in the salt. Therefore, password_hash will 
attempt to use the salt directly (if it's valid in the base64 character set). 
But any character outside a-zA-Z0-9./ and it'll base64 encode the salt first. 
You can test this yourself:

echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' => 
'thisisatestthisis test'));
echo "\n";
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' => 
'thisisatestthisis test'));

Produces the same result twice in a row:

$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO

Which indicates that it's actually encoding the salt you pass in, rather than 
generating a random one.

So it's still using your salt, and it's most definitely not failing.

Closing as Not A Bug. Thanks for the report!