I spent all yesterday thinking about that...
The odex file is only valid when used with the exact BOOTCLASSPATH files. dalvik enforces this by storing a checksum of each file that the odex file is dependent on, and ensuring that the checksum for each file matches when the odex file is loaded.
When you are deodexing an apk, even if you don't need to set BOOTCLASSPATH for it (because you don't get any error msg while baksmali), by default these 5 jar are already included in the classpath: core.jar, ext.jar, framework.jar, android.policy.jar and services.jar. This means that an odex file has dependencies on every "BOOTCLASSPATH" file that is loaded when it is generated.
So i was thinking about to deodexing every apk in /system/app a part Browser.apk (i.e leaving Browser.odex) and try to figure out which jar file inside /system/framework has to remain odexed.
Maybe we can still have overscroll glow mod, renounce to have the extended power menu in order to get an HW accellerated Browser!
I don't know if it make sense for you as my english need to be improved