Thanks for the reply Andy. I know I'm probably over thinking things, and by all means I'm not trying to find fault. I'm just thinking in terms of flexibility, things I *might* want to do with it...
You're right, I probably don't need the dedicated input pins, that could be accomplished through the keyboard encoder... but I'm pretty sure all the inputs on my current ipac are full, plus (unlike most people, I think) I actually have several different keyboard mappings set up for different things and I'd have to tweak them all. Not a big deal, so long as I've got some free inputs.
What I *would* find most useful would be a couple of output pins indicating the state so I could easily drive indicator LEDs, which I personally would use to illuminate the sticks one color when they're in 4-way mode and another in 8-way mode. I'd also like a built in toggle function so I only need one button on my CP, to simply invert the state irrelevant of what the current state is. It looks like right now it supports commanding it explicitly to one state or the other but has no "toggle"?
The ability to query the state would allow me to implement a toggle myself... query the current state then command it to go to the other state, if the device doesn't implement it's own toggle. Again, not critical, but I'm an EE so I tend to overthink things.
Many people probably wouldn't use these functions, but I think they'd be cool.
I agree that adding parts increases costs and it's desirable to keep that to a minimum.... if there are free GPIO pins on the uC you might consider making them available as solder pads or through holes on a future rev, or run them out to a footprint for an unpopulated header. The majority of users might have no need of the functionality but I for one don't mind doing a little soldering to use an advanced feature so long as it's supported.