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

false/true/null/etc are not valid key names. Please read the manual for what is valid and what isn't. This is no bug.

This isn't exactly the problem. The problem is that the error 
message produced is incorrect -- not that the error shouldn't occur. 
It should not have an unknown file and a 0 line number, but rather 
the file and line number where the error occurred.

This is probably superglobal-array-specific, and seems to apply to 
any numeric key.

Reopening.

Rebogused: This is not possible to change and that's how it works.

This is clearly a bug in PHP.

The answer from jani@php.net leaves too much to desire. Seems like jani was "washing their hands" and leaving the problem to anyone else.

Hi,
I just encountered with this problem.
my session was like $_SESSION[0]['someid']

and i changed it to $_SESSION['someid'][0]
now it works fine.

Hope this helps you

Just to elaborate a little bit on why this didn't work for future readers. 
register_globals. PHP 5.4 has removed support for register_globals, so going 
forward you can in fact use numeric keys with $_SESSION. 

$_SESSION is a super global variable and they were treated "special" with 
register_globals. One of the things that makes a super global special is that it 
exists in all scopes without needing to use the 'global' keyword. With 
register_globals the other thing that made it special is that it creates 
variables for all of the child elements automatically... again in all scopes.

$_SESSION['username'] = 'Test';

The above would also set a variable $username = 'Test'; So if there was a 
$_SESSION[1] 
= 'Test'; It would attempt to set $1 = 'Test' which is not allowed. So when jani 
said it was not possible to change, what was meant was it was not possible to 
change without 6 years of planning to remove register_globals support.

Replies to this continue to miss the point... The bug is not that the functionality around $SESSION is a wrong. It is that the error message is unhelpful when a person trips over this.

NOTE: The issue also happens when using this:
  $_SESSION[] = 1;

Or this:
   $row = <function that returns array from PDO::FETCH_BOTH or PDO::FETCH_NUMERIC>;
    if (!empty($row)) {
      foreach ($row as $key => $val) {
        $_SESSION[$key] = $val;
      }
    }

Shouldn't the message be something like:
  NOTICE: Unknown: Skipping unsupported numeric key assignment in $SESSION array.

And if possible (though I gather it's not), seems it should indicate the offending line of code.