WTH: I want the voice assistant (Assist and Alexa) to execute commands regardless of a device’s reported state. For example, if the light is actually on but reported as off, and I say “turn it off,” it should simply turn off. That’s all I’m asking for.
Is it common for you to have devices that do not report their true state?
If the device is not reporting its current state properly, it’s likely it will not accept your command, anyway.
I agree. No system should pretend to be smarter than the user, don’t be a Microsoft 
And of course the underlying problem should be fixed too. But nothing is more irritating than a system telling you that you can’t do something because it is already in that state. There can be good reasons that a user wants to do it anyways.
I don’t necessarily disagree with you, I am just struggling to think of a scenario where this is true. Can you provide some examples?
An example could be localtuya.
I have migrated some of my devices to it, but some have difficulties reporting the correct state to HA.
But, I think some more tinkering could solve that with my local tuya setup
I have started using a local LLM (via Ollama integration) with the new voice assistant device. It seems that the state of the exported devices are fed to the LLM when it is loaded into memory, along with the a priori rules and description, so this becomes static context and it is not updated. My llama brain is configured to unload after 2 minutes, so info for things like temperature and weather sensor data is never particularly stale, but devices such as lights which might be switched on/off by automations would be a problem. For the time being, I have elected to not export such devices.
A better solution for me, though, would be to update the state of each exported device when each voice command is issues. That’s arguably a problem for the Ollama integration itself, I suppose. The LLMs have limitations on context, so that seems to be a generic problem.
I have a device for which this is not true. It’s the controller/thermostat unit of my heat pump. It reports its state correctly, but with a delay that is sometimes minutes. Not sure exactly how that works, but it’s not local unfortunately, I rely on a custom integration and the manufacturer’s server. Anyway, it will respond to commands to change the temperature almost instantly, but report the changed temperature with a long delay. So it’s a one example for why this WTH is a good idea. Anyway, if I give a voice command about a device, I want that command to be sent to that device. Period. If the light is already on, sending the command to switch it on won’t be a problem.
this happens all the time with MQTT lights and switches, its weird that so many people seem to be scratching their heads here. nearly every device only updates its status when something changes. if that change happens when home assistant is offline, busy, or whatever, it wont’ have the correct status for the light, same for if the light is switched off at the switch. the light will do what it does, and won’t change in home assistant until it is told to change. if you tell the light to turn off, it will always turn off, but there are plenty situations where home assistant will not know! its even worse if you are using ZHA with bound switches, home assistant will almost never have the correct state for those lights because it will only know what it has told the lights.
My ceiling fans are a perfect example. Controlled via Bond RF controller or via a regular remote. The communication is one way. If they’re only controlled by the Bond (or HA) the state is accurate but the moment someone uses the remote control they’re state in HA is no longer correct. Bond specifically has an option to address this but the other way around. It does not trust tracked state by default.
This is a fair example. It seems all the examples are just to support devices that are not built to be controlled by a centralized system. Home Assistant prides itself on supporting tons of devices, so this is a fair request.
However, I think this also shows why you should avoid purchasing devices that cannot be polled.