If your plugin is broken in IE9, you should fix it. Using X-UA-Compatible to force the browser into IE8 mode is not a fix, but a quick and dirty workaround. (Because you didn't fix it for IE8, just told IE9 to behave like IE8.) Yes, fixing browser bugs is a pain, but unfortunately a pain we simply have to endure.
I think it's wrong to give plugins the possibility to break the template. Even if it's just in the edit mode, it still means that IE9 users will get a different experience than the one that was intended. Especially when you change to compatibility mode in between modes, most users will get confused and think something is broken.
And what should happen if your plugin wants to emulate IE8 and a different plugin wants to emulate IE7?
You should either fix your plugin or tell your users that you don't have time for that at the moment and they can remove the X-UA-Compatible line in their template themselves but need to be aware that this will break other things.
Two other reasons for not moving the line further down:
* "The X-UA-Compatible header [...] must appear in the header of the webpage (the HEAD section) before all other elements except for the title element and other meta elements." [from: http://h5bp.com/f
] See also http://blogs.msdn.com/b/ieinternals/archive/2011/07/18/optimal-html-head-ordering-to-avoid-parser-restarts-redownloads-and-improve-performance.aspx
* And it can only be invoked for Chrome Frame if it is within the first 1024 bytes [http://code.google.com/p/chromium/issues/detail?id=23003].