As it was written, you need to write some more tests for such changes. It required a few iterations before we got SetWindowLongPtr(GWLP_WNDPROC, ...) right, so this might be also not easy. The tests for SetWindowLongPtr are in dlls/user32/tests/class.c. Some things I can think of that requires checking:
1. Is the edit class still special after changing the winproc - does the unicodeness of controls created after the SetClassLongPtr call depend on whether CreateWindowA or CreateWindowW was used 2. Does the same winproc really receive both Unicode and ANSI messages. That's the strangest thing in your patch. Does calling SetWindowTextW and SetWindowTextA call the same function, but once with a Unicode string in lparam and the other time with an ANSI string. 3. Does GetClassLongPtr[AW] return an address or a winproc handle (there is a IS_WINPROC_HANDLE macro in dlls/users32/tests/class.c). The same for GetWindowLongPtr[AW]. If point 1 is true then it would be good to check it for controls created with both CreateWindowA and W 4. Does this apply only to the edit class or to all built-in classes. The edit class is special from the point of view of GetWindowLongPtr so it may be also special here.
I think, knowing the answers to these questions would make it easier to create a good patch. This patch seems very strange as it seems unlikely that the same function would be used for both the A and W calls.
Mikołaj