Object literals and scalar type hints won't be in 5.5. Scalar type hints may be in the next version (it's a rather tricky topic). For object literals I don't see reason to add them at all (in PHP you can just use arrays ^^).
JSON is everywhere these days, supporting object literals is a very, very big deal; I understand which features to implement are handpicked very carefully so as not to clutter more the core, but we are talking about making the life of devs who use and write JSON more difficult, and that happens to be lots of folks.
Telling people to use arrays and be done with it is the equivalent of implement a strpos function that may only accept a string that's 5 characters long — yes, theoretically you can work with that splitting your strings, but that's time consuming and a inconsistent behaviour (why would 10 character long strings be less of a citizen than 5 char long ones?)
Because 1) PHP syntax for object literals is non-existent 2) JSON is used in many more places than just Javascript and 3) the syntax of JSON makes sense; it's compact, human readable and easy to write. I'm not suggesting copying it 1:1 verbatim, but something close to JSON would definitely be an improvement. See for example how MongoDB uses a JSON-like syntax to great effect.
You can already use the js-style shorthand inside of Twig templates, and I've been caught absentmindedly forgetting to switch to the 'proper' way for raw php now and then. And I would like to never need to even touch the shift key when having to write out an array or an object but even JSON won't let you do that. It's a step in the right direction, though.
Otherwise, if we still had to write "array" each time, I'd be more supportive of the object-literal, although I do think there's value in the literal but mostly to make the language similar to other languages with similar constructs (js, py).
Personally I think there should be a way to create objects right away instead of having to cast an array. Maybe there is a good reason all together for not using objects but I very much prefer typing $var->field instead of $var['field'].
I believe by design it will always be:
$foo = $o->foo;
$foo();
Using __get/__set behaves the same way. Let's say $o is of SomeType that defines those magic methods. You can have a function foo on that type that is defined as a public method.
$o->foo(); // the actual instance method
$o->foo = function() { print 'bar'; };
$o->foo(); // same instance method
$foo = $o->foo;
$foo(); // prints bar
In the case of StdClass it might be possible to do it your way where foo could be callable ($o->foo()) but I can see why they wouldn't allow this in order to keep things consistent.
Edit: It also behaves the same way if you assign a function to a public field of a class (I'm using 5.4) so I actually support not allowing a method to be directly callable in this fashion because this would be the only case where this behavior would occur.
Object literals and scalar type hints won't be in 5.5. Scalar type hints may be in the next version (it's a rather tricky topic). For object literals I don't see reason to add them at all (in PHP you can just use arrays ^^).