I don't know if there's a definitive answer to this question, but how big a deal is it to recompile (Correct word?) a 32 bit app as a 64 bit app?
"In theory" it should be very easy to do. But the people writing the system often take advantage of this "forced code review" to make changes to their API calls. If you try to just do a "find-and-replace" to update an old function call to a new one, you often will find it's not compatible because parameters have changed. Creating a sort of example, lets say a program needs to draw a window so it calls DrawWindow32(x,y,w,h). But now that the new OS has "themes", it needs to know the theme the window is drawn under, so the new call is DrawWindow64(x,y,w,h,t). Trying to omit T will cause a compile error that you will have to fix somehow, either by passing in the current theme or a default value etc. It forces you to review your code.
If enough of these change formats, it can be quite a headache to have to go review dozens, or hundreds, or even thousands of these "breaks" and fix them all. Return values also will change type, from 32 to 64 bit, as will data types in blocks of data. Numbers could be too big for your current 32 bit code to handle, and you will have to adjust them so you don't overflow. The above call may return the WindowID of the new window it created, and if it's a 64 bit number now you will need to be able to store it, so everything in your code that referenced the WindowID will need to be adjusted. And this can get out of hand very fast. A few dozen function calls being updated can easily lead to thousands of lines of code that need to be changed to handle the higher precision. Also, each and every one of those changes you have to make could introduce a bug. So after making changes to 2,000 lines of code scattered far and wide within your app, just how many bugs do you think you've managed to accidentally create?
This is NOT something developers are looking forward to. It has to be done, but it's not going to be pleasant for a lot of developers and even some users.
Tangent: I leverage this "side effect" to my advantage when coding. If I change the behavior of a function in a way that doesn't cause the call to change, (and thus it will still compile without error, but not RUN correctly) I simply rename the function. Add _1 or B or something to the end for example. NOW the whole world blows up, as every call to that function breaks, requiring me to go fix the name in each place I call it. While I'm there, I adjust the code (if necessary) to accommodate the change to the function. As an example, maybe it was handing back a number indicating how many items are in a list, a list that USED to have a max of 10 items, but I've upgraded it and now the max is 20. 10 and 20 are both easily handed back using an INT so the compiler is happy, but maybe some of my code can't handle more than 10 (or 15?) items at a time and needs to be adjusted. So the compiler drags me by the collar, from one call to the next, so I can make sure I review each and every one of them without missing any. This has become a very useful and reliable coding practice for me. Sometimes I will then find another function that needs to be changed as a result, and so that too will get renamed. Sometimes this has a "domino effect" in my program, leading to a dozen or more function changes. It's SOOO easy to miss something that needs changing, especially when there's so many places each one of them needs to be reviewed. This insures I hit every one, no matter how crazy things get.