Yes.
Sorry. perhaps we weren't clear:
We are required to disable Flash when the device runs out of memory.
The alternative is that the device will likely reboot.
The problem is that you can't simply automatically re-enable Flash when the device recovers from its low memory state.
Consider this real example:
Here's the simplest algorithm that everyone suggests:
As the tablet is configured, there are a number of processes that assume (yes yes assume) that they can successfully allocate memory. If they don't, bad things will happen. Some of them will be respawned if they crash, and some won't.
If the X-server crashes because it can't allocate memory, your device is dead, because some processes are connected in interesting ways and won't recover when X goes away. As such, the device is programmed to reboot when this happens.
Linux on our device doesn't actually work this way, at least, not usually.
Instead when an application asks the kernel for memory, as long as it's not outrageous, the kernel says: "sure, um, here's a page pointer, have fun". There are various reasons for this (you can read about kernel overcommit if you're interested), instead it only actually tries to find real memory for the process when it tries to write to the page (pointer) it was given. In this situation, you might say that the application has called the kernel's bluff, and that it was caught with its pants' down. The application (e.g., the Browser, or the X server) is in the right. But the kernel is not really in the wrong, it's following orders (see overcommit policy), the kernel gets desperate and calls the out of memory killer for help (you can look this up).
The out of memory killer has some rules about what it can kill and what it can't. In the end, it must kill something or the device will have to reboot. In some cases the killer is lucky, finds a safe victim and life goes on (this doesn't help us, we need 200mb, and you won't get that no matter how many processes you kill). Sadly, sometimes it gets creative and kills something important, like the browser (in which case you lost a lot more than just the Flash Applet), or the X server (in which case you lost everything).
The problem is that we have a very different API for handling plugins....
The way Gecko worked in 1.8 (this is sorta different in Firefox 3, but that happened long after MicroB's code), all plug-ins found in certain paths are available (unless some other plug-ins handle their mime types).
In order for MicroB to support the requirement to dynamically disable Flash, the most obvious method for a simple hacker was to delete a symlink to the plug-in from the file system ("disable") and put it back ("enable"), with no distinction between when the user does this from the menu and when the host does this as an act of desperation.
This shouldn't really be the case, in theory, there are directory service providers, and MicroB probably should have a "Flash Plug-in Directory Service Provider" which either does or doens't return a directory that either contains (if the user left it enabled) or does not contain (if the user disabled) the Flash Plug-in. Such a provider would only return the directory if the system hasn't been low on memory since the browser launched. However, this would also mean that the browser would somehow need to enable the user to poke the browser to reexpose the directory if the user wants Flash in the current session even after the browser ran out of memory.
Trying to explain a tri-state field using a duo-state widget (checkmark) is very very hard. And probably beyond our pay-grade. Plus, testing and verifying those conditions is painful.
So for now, you've learned the story, and you know that if you want to, you can reenable Flash by clicking the magnifying glass, components/plugins and selecting Flash.
Normal users could consider installing Flash Block or something like it. If you're lucky, with that installed, you'll rarely experience the browser automatically disabling Flash, because the only times you'll trigger Flash aren on sites that you know and trust (not to try to overload your device).