From the PHP manual about unserialize():

In case the passed string is not unserializeable, FALSE is returned and E_NOTICE is issued. 

The solution: Use NULL instead of false

But the string "b:0;" is unserializable it returns false. Also from the php manual on unserialize

FALSE is returned both in the case of an error and if unserializing the serialized FALSE value. 
It is possible to catch this special case by comparing str with serialize(false) or by catching the issued E_NOTICE. 

I've submitted a pull request that handles it correctly.

I know, but this type is called "object", so setting it to false makes no sense. Setting it to null makes sense though.

I know that b:0; is false, but why do you set it to false anyways? Objects are either null or an instance of the object. Never false.

I'm storing settings in a database. using a Namespace, Key => Value triplet. I don't know what might be stored in the value part. Currently strings, NULL and boolean data are stored. Using object seem to be the best approach. (ArrayTypes have the same problem).

If you think a different type would be better then please let me know.

how is such a triplet only b:0; ? or is your entity the tripplet and the variable that fails is the value?

I've added my entity. The entity is the triplet. And it is the value that fails if false is stored.
It allows me to store the value(false) but the throws an exception on loading the entity. It should allow the loading of the value(false) or disallow the storing of a false value.

Although this should really be just array and object, not strange false types i added this patch to prevent future reports of this as a problem. The loosely typed language PHP can go with null or false, so why throw people stones in their way.