$input->getArray() and $input->get->getArray() are referencing two different objects. The former is a reference to the $_REQUEST superglobal and the latter a copy of the $_GET superglobal. When the application routes, it sets any non-defined values it finds via $input->def() so the values are getting assigned to $_REQUEST, not $_GET.

So I'd borderline say this is expected behavior since the application is both using a copy of $_GET (so it's not being updated if you set new values via $input->get->set()) and setting non-defined route variables to $_REQUEST versus $_GET.

I think I understand what you're saying.. but then, why can I get a specific GET value (on the same scenario), such as $input->get->get('option') (which returns 'com_content', for example), but I can't get "all" GET values (which is what I need) using $input->get->getArray() ?
Or in other words.. (although this isn't the place for this I guess), how do I get all GET variables passed in a request? (when SEF is on)

When SEF is on, not all the app variables are in GET because they aren't part of the query string. So you'll have to dig into REQUEST to grab them. You can do this consistently with SEF on and off, only problem is you effectively have to filter out all non-routing related data.

I guess one other hackish way to do it would be to duplicate JApplicationCms::route() and parse the current URL through the router again so you get back all of the route vars as defined with the routing system and the menu item associated with the route.

I guess this can be closed then?

I guess this can be closed then?

There's no core issue so from that aspect yes.

Thanks @mbabker . Yes that's how I was doing it.. I was getting all available in REQUEST and then removing all what I don't need (basically COOKIE stuff).
Yes @brianteeman looks like this is not a bug so it can be closed.

Closed