I see three potential options other than the one I have which is two versions of NSIS, meaning two sets of plugins (but one codebase) and two sets of scripts, which I concede can be unwieldy.
1. One makensis.exe that can generate both an ANSI or a Unicode installer. This means that there will still need to be two sets of plugins and exeheads, but potentially just one set of scripts. If we go this route, I'd suggest that all scripts are Unicode. If we start with ANSI codepage scripts, mixed scripts in a single file becomes very difficult if not impossible to support. (Imagine a single string with mixed scripts.) And we would alienate Unicode-only languages.
2. We generate one exehead but with the ability to on-the-fly convert the internally stored Unicode strings to the ANSI codepage strings to call the ANSI Windows APIs on Win9x machines. This requires that we have a small but portable implementation of wide string to multi-byte string conversion function. Maybe we can leverage some code in the Wine project to do this. But it does mean making the exehead and therefore the final installer to be bigger. The plugins would also need to do this conversion as well since they would likely get the Unicode strings on the stack. So this method requires more complexity in the exehead and the plugins.
3. Drop ANSI support in NSIS 3.0 entirely. We have one version of everything going forward, but we lose the Win9x support. But as Joost mentioned, NSIS 2.0 can cover that small and rapidly shrinking market. (The Win9x crowd is ~0.2% of the web surfing public according to w3school: http://www.w3schools.com/browsers/browsers_os.asp
I think the logical choice is 3. But it isn't my decision.