> 3DS and Vita are about the size of a raspberry pi and with some added sensors and controllers.
Sure, you could create these things in a PC format, but what I'm getting at is that nobody has. They don't make sense in the current PC market. Selling games that need special non-universal peripherals is really hard. Not impossible (Guitar hero pulled it off), but very difficult.
The HTC Vive is a good example of that. It's about as close to a general peripheral as you can get on the current market (and even it strays irritatingly close to "platform" status). But VR is a wildly niche market. It's nowhere near the market penetration of the 3DS or Wii.
I don't mean that those peripherals can't be built for PC, I mean that we don't have compelling evidence that it makes sense to build them primarily targeting PCs.
> to make running any software and take advantage of any hardware.
You can tune a game way more if you're not targeting 'any' hardware -- it's a lot easier if you're targeting one piece of hardware that works one way.
Take a look at the incredible work that emulators like Citra and Dolphin are doing right now. Reverse engineering the API is only one piece of that puzzle, another big challenge is dealing with the games that are designed to take advantage of hardware quirks and undocumented behaviors.
It's a huge simplification to say that those emulators/games are just based on the API and nothing else. They're often emulating wildly specific behaviors that wouldn't be standardized across multiple implementations of the same API on multiple pieces of hardware. That's why its a such a huge engineering challenge to build an emulator in the first place -- you're constantly balancing accuracy and performance, figuring out when you need to load and emulate specific hardware features.
> Rendering APIs, hardware controllers, and sensors are all standardized. What more do you need?
If you make a game for Switch today, you need to target one aspect ratio at two resolutions, and a very small, finite set of controller layouts. If you tried to release a PC game with those kinds of restrictions, you'd be laughed out of the market.
As someone who's currently working on supporting multiple controllers for a PC game, it's really stinking annoying. Even aftermarket XBox controllers will occasionally just report entirely separate button layouts depending on the OS they're being used with. I can't even just read the hardware codes and base the layout on that, I have controllers that map buttons differently depending on whether I'm in Ubuntu or Manjaro. Libraries like SDL2 help a bit with that, but even then the situation isn't perfect and you often end up making multiple control schemes that degrade gracefully when features are missing.
And from a consumer perspective, minimum requirements for PCs aren't really a scientific thing. People don't know what their GPUs are, they don't have that information in front of them when they go to a store. They buy games as gifts for other people who's PCs they've never seen.
Compare all that to, "does Billy have the Wii U? Cool, then Smash Bros will just work on it."
You could have something like that in the PC space if everybody got together and we had industry-wide standardization on certain requirements or parts for PCs, I can imagine that existing. But it doesn't exist right now, and it's not clear to me that most PC game developers would want that (I wouldn't), and it's not clear to me that current PC-gamers want that (I don't).
It's not a propriety vs Open thing. If someone wants to make a console that has all of its specs completely open and uses off the shelf parts, then fine. Consumers won't care either way. Consumers care about being able to look at exactly one logo on a game disk that indicates the game will play perfectly on every device that shares that logo.
The PC market is not even close to that goal, you're greatly overestimating how standardized even the average Windows install is, and that gets even worse once we start talking about more freedom-friendly OSes like Linux.