In this case, I partially agree with you. One of the things I tried the hardest is to reduce the changes in-game, in order to keep the old game systems and functions working as they were intended. That is why I always search around for unused bytes on structures in the game to place them on. The sethealingplace one also annoys me a bit, so I made a few fixes and now mimic the old code if no values are placed in the variables. Next release should fix it. If you know of any other that messes things the old game should do, feel free to tell me so I can fix it.
Lastly, about the specials, I used these in order to simplify usage. The main objective of this hack is to provide a number of new features with simplicity of use. The main reason I try to mantain retro-compatibility is so that anyone who uses this hack doesn't need to learn new info that conflicts with the original games, and so that we can use the good tools out there we used to use.
Actually, the only reason I didn't implement a berry growth system yet is because of three simple things.
First, I have no way to display the berry trees in their growth stage. Berry trees aren't typical sprites, so there is no way to simply copy them and paste them on a new OW table. And I have near zero graphical skills, so creating berry trees from scratch would be nigh impossible.
Second, the in-game costs. You would need a variable for each berry patch, plus one other variable for all the data relating to current growth time, growth stage... I've made some studies in this matter, and could get 256 berry patches in the same way as the Dynamic OW switches, by using a compressed data system that would use the last 6 or 7 bits of the variable contents as the entry in that table (as there are less than 63 berries, if you want up to 127 berries, the growth time had to be sacrificed). And would require a secondary data table, to keep all the growth time tables, types of berries, and other data.
Third, I don't really believe in the RTC mechanics. I appreciate the work made by interdepth, as i checked it out and it's quite good, but I always disliked the fact you had to play at a certain time to work with it. Also, I would have no way to test anything with RTC, as my computer seems to hate it, and wouldn't have the time to make a full debugging of that function.
So, following all these reasons, I must say, if problem number one was fixed, I could probably go around the other two. Myself, I would prefer a simulated time system rather than a real one, and would more easily implement one and use it.
As for the second suggestion, porting the Contest system from R\S\E onto Fire Red would be really hard. Not only would it be necessary to know where all data related to the contests was, as well as routines, you would also need to find out which pointers to routines are also present in Fire Red (like the OW Map function), which to keep, which to change, and finally, after all that, we would need to repoint the data stored in the RAM so it doesn't overwrite the used by Fire Red. The amount of work required for that one would be so great, it would probably be best to remake it from scratch. So this one I might state that will not be ported to Fire Red.