The Fremantle release will certainly improve on the scrolling issues. Don't expect fat scrollbars, for one.

Anyway, about the main issue: for the size detection, there were many reasons for removing it - some rather technical and unfortunate realities - but I guess it boils down to making choices about the UI. We're going towards finger usability. It is certainly not trivial to design two good UI's for the same amount of information or contents. Yes it can be done in some pre-defined cases, but to have it system-wide and as a functionality that scales as an indefinite amount of extra information is added to the UI, not so well anymore.

The harder you try to hold on to dual support for stylus and thumb, the more you are constrained in your thinking about what would be a good touch UI. Take any issue. Take multitouch, for instance. If a device would plan to support multitouch properly - and multitouch has not been announced for any release or device - you cannot really do it, if you must also ensure that your designs work with a single touch, i.e. stylus. You can do some "additional nice stuff" with multitouch in a situation like that, but cannot change any core UI thinking.

Also widgets, the UI components. If supporting a stylus, you can still cling on to components like checkboxes, scroll bars etc. With a dual UI, allowing components like that will mean that those will get used, and therefore there should be two versions of those, and usually the finger based alternatives being the "suboptimal" ones of those two.

Finger vs. stylus halves the amount of UI space available for a given UI. It is not possible as a system-wide issue to design UI's for all the applications that would be 'optimal' for both stylus and the finger at the same time, unless nearly doubling the design and implementation effort.

So for "it could have been as simple as that", I don't agree.