Given the above, if allowing editing of macro-enabled documents without needing to touch the part of the file that has the macros, requires as much debugging and testing as you imply, great enough to just not even bother trying, then there's a more fundamental structural problem somewhere and I don't even need to see the code to know that. "fixing bugs in the sound subsystem can break printing" anyone?
The problem is not whether you can open the file as editable. It's whether you can save it back again afterwards without deleting all of the macros. In order to save those macros back after you're done editing, you're going to need to parse them out in the first place so that you have something you can serialize back later. If you don't need to save back later (i.e. the document is readonly) you can just skip over the macros, but if you do need to save, you need to parse them into memory so that you don't lose them on the save back to disk.
Also, nobody is saying that enabling macros is a huge amount of work. I'm just saying it's more than zero amount of work, and that the people who would implement this feature aren't sitting around doing nothing. Doing more work requires a decision that the new work is more important than the current work that is being done.
Let's say it takes three man-weeks to make the document have macros that are editable - that's two days to put it in, a day to merge it, a day for MSEC to check it and two weeks to build unit tests and fix the bugs that inevitably occur. That's three man-weeks not being spent on other stuff.
So my question isn't should Microsoft implement macro-disabled documents being editable or a statement that it's too hard, can't be done. It's what stuff would you like the WinPho-Office team to not do, so that you can free up three weeks in their schedule for this feature that so far as I can see is being asked for by 4 people.