I think we really need patches to be done as distinct managable patch files, plus an explanation of what they are for, plus testcases to demonstrate what they do.

Having a look at the zip file for the things that I'm most involved with ...

sqlcient ... at first glance this patch just reverts code to an older version and is wrong, but perhaps I'm missing something.  If I'm not, then this patch can just be removed.

make ... this looks like three parts:
1. a change to Testing.h which is just wrong/unnecessary
2. huge change to 'configure', which shouldn't be in a patch since it's regenerated automatically
3. change to configure.ac to change the default library combo on apple systems ... but why?  Maybe there's an argument for it, but presumably it would be a nasty surprise for people using the existing code.
Maybe this patch should just be removed, or maybe there's good reason for the last part.

base ...  too big to give a quick response to.  this needs to be broken down into sections.  Some big things I see:
Changing to use symbolic constants consistently in version macros ... I like.
Large changes which just make indentation inconsistent with the coding standards ... we need to remove that sort of thing from any patch.
But in general, other changes can't be evaluated quickly ... there seem to be a lot of unsigned->NSUInteger changes, some of which appear to be in non-apple APIs which shouldn't be changed this way, but some of which probably do need to be changed.  We need to check which is which on an individual basis.