Monoply's patent was challenged and invalidated because of prior art. This was discovered during the anti-monoply legal battle.

Another example of a board game patent is on Khet. Claims 31-54 cover the play of the board game. It isn't unheard of for boardgammers to poke around expired patents (yes, the search is broken) for games to implement (the biggest challenge being translating legalease back into board game rules). Most games that I've come across while looking at patents I've never seen implemented/sold. Oh, another game that is covered by a patent - icehouse. Mr. Loony was quite happy and even made a Tshirt of it. Yes, that hippy is very much into patenting his games (though he also has a freeware licensing policy for computer implementations of his games).

One tends not to go to court to challenge a patent that is valid in the first place

On iTunes the 'Summary' tab has a set of options. One of them reads 'Encrypt iPhone backup' as a checkmark. Poking about my system (~/Library/Application Support/MobileSync/Backup/...) I can find some of the raw data that on my phone there (settings, files). So, it is possible to encrypt that data as the backup is stored but it sounds like that the unencrypted data is what iTunes accesses.

My aunt also needs a device that lets her send and receive email, look at pictures, read books and read news... without having to call tech support when someone gets through some exploit in a forgotten service and rootkitted her machine. Ideally, this machine would also use a cell service so that her somewhat technical children don't need to go and set up wifi for her. It should also be able to easily access and download applications signed by a reputable authority.

The majority of people out there are not tech savvy geeks. I personally would love a locked down interface designed on top of Linux that is as easy to use as some iDevice that fills all of her needs. Unfortunately, it doesn't exist at the same level as the iPad today. I don't want to have to drive down there and fix her computer every month, nor help her install (or uninstall) some program that isn't working right.

Android may be a nice alternative some day. It isn't here now. Nor is there any android equivalent of a genius bar that I can have her go to when something doesn't work (so I don't have to drive down there). There is more to a given device than what OS it runs.

Assuming you have an intel mac of some sort, you can download the sdk and work in the iPhone or iPad simulator without having to pay to be in the developer program. You will need to register as a developer, but that is free.

No, I'm imagining a situation where apple changes the underlying architecture of some a device (like they did with ppc to intel). The instance on xcode mirrors what happened back then. People that were properly using XCode and Mac APIs would find that with one click they could compile for intel and continue on their merry way. If you are bundling your own framework and translation libraries with every application, you would have to wait for that company to come out with a new build.

Lets imagine a world where Adobe and Novell (Monotouch) control 75% of the market and Apple comes out with firmware 5.0 with a bunch of new features. The adobe users would have to wait until Adobe gets around to releasing a new version. Novell would be waiting around until android catches up so it can again release for the lowest common denominator.

The lowest common denominator is what apple never wants to have its developers writing for. Apple believes they have the best product out there for user interface and design and sees this as its competitive edge over other mobile OSes. For its developers to write for that target means they will never have anything that is better than what other mobile OSes have.

Apple would start going and imposing more specific restrictions on apps. For example, if your app size is too large (monotouch hello world is 5mb while objective c is 50 kb) it gets rejected. If the app memory foot print is too large it gets rejected (garbage collection is automated in flash). If the app doesn't play nicely with multitasking in 4.0, it gets rejected. If the app doesn't run under hypothetical future architecture it gets rejected. Etc..

Any of these technical requirements would reject apps written under other frameworks without saying "must be written in C / C++ or Objective C".

Even if Adobe wasn't giving up on the flash to iDevice, consider how far behind they will fall when firmware 4.0 is released. How long would it take Adobe to release an update that handles background services, voip and other new features?

This really is the crux of Apple's restriction. If Adobe (or any other iDevice packager other than Xcode) became the dominant platform, it would be up to that company to add in new features that the previous firmware released. Apple has been burned by Adobe before and doesn't want to be beholden to anyone to have support for their firmware now. This is also likely why HP bought Palm - so that HP wouldn't have to wait for Microsoft or Google to do something new and game changing.