For an easy demostration of an array of values being passed, open edit.php in your install with post_format passed as a query var, eg. wp-admin/edit.php?post_format=aside.

I'm not sure why that particular query puts the post type into an array(it shows up as an array inside the WP_Query object to). Passing &post=type=post into the query string does not change the outcome and i'm not sure on what the cause is, the only place i could see any $post_type variable cast to an array is inside update_post_caches(), though it's my understanding WP_Query does support passing an array of post types to the query, so perhaps it's a side-effect of something there.

Tested without any plugins enabled, and with the theme's functions file stripped down(ie. empty).

NOTE: Despite the notices, the post_format query var does work, and return the correct result set.

Should the global be getting filled with an array of post types anyway? I've always been under the impression it would(or should, perhaps?) contain a singular string value denoting the type of post type page you are viewing admin side, ie. if i'm managing a "book" post type, that value is naturally "book", and not necessarily array( 'book' )...

I can understand why WP_Query supports an array(for grabbing a result set of more than 1 post type), but should the global also contain an array of post types?

The issue is _post_format_request(), which hooks into the request filter and corrects the post_type query variable based on the post_format's object_type setting. object_type is always cast to an array, even if it is singular.

In the admin, post_type will always be singular wherever we use wp(). So what we should also do is prevent the callback from overriding the post_type query variable in the admin.

Finally, this gets extracted into the global namespace via WP::register_globals(). There's little reason for the query variables to be extracted back out into the admin namespace when we call wp() on edit.php and upload.php. Erick tested bypassing the query_vars extraction in the admin, and nothing seemed to break, but I'm sure some plugin is doing something terrible there.

Regardless, I agree with 18475.diff​. One less global to rely on. I'm also going to fix _post_format_request().