The other thing is that they have partially fixed the most "wat" bug in PHP: for some arrays that aren't even all that hard to come by when interacting with JS,

The other thing is that they have partially fixed the most "wat" bug in PHP: for some arrays that aren't even all that hard to come by when interacting with JS, the following code could change `count($arr)`: foreach ($arr as $key => $val) { $arr[$key] = f($key, $val); } The issue is that `$key` could be a string describing an integer, but `$arr[$key]` will automatically see that you're using a string-int and convert it to an int-int, setting a different key than the internal one. It's only a partial fix but it hits the most common case: you have a JSON payload that happens to have an index of objects which happens to have been given numeric keys: { "abcdef": {"prop1": "hello", "prop2": 123}, "987132": {"prop1": "world", "prop2": 456} } If your framework hands JSON to you as a StdClass object then you would typically convert this to an associative array since that's semantically what it is: as opposed to the internal entities, which in this case appear to be full-fledged objects. (The difference is that the keys of a full-fledged object should be known in advance at a data-schema level and have a control structure of getting/setting `->prop_name`; the keys of a dictionary should be user-settable and have a control structure of `foreach ($dict as $key => $val) {}`.) So the bug still maybe exists in some fringe cases as the underlying cause is not treated, but it is now autofixed by the common idiom of casting `$dict = (array) $params->dict`.