Opinions: Non-tech-client managed multisite???

I'd like your opinions.

Client has commissioned 9 of their sister organizations sites to be redesigned/redeveloped as Drupal sites (actually 1 already is Drupal). They want each site to be independent, but share some content, such as a common events calendar -- which I intended to do with Views/FeedsAPI. They have asked that it be done as a Drupal multisite, with only shared codebase. I believe that they think multisite is the only way to share content. Client is non-technical (no web specialists) and not familiar with Drupal, but wants to be able to maintain it themselves.

I think that this is a bad idea. As I start the development process, I keep imagining having to explain certain things to them -- i.e. multisite file paths and URLs. As someone newish to multisite, I find myself getting tripped up by it -- writing them out as I would for a standalone site, by habit. So, I can imagine that they will find it confusing. I keep trying to find tricks to simplify this, but no matter the trick (mod rewrites, symlinks, apache rewrites), it won't create a consistent approach for all scenarios and modules. This in on top of me needing to teach them to use Drupal as content publishers (user roles, permissions, nodes, block management, etc.)

I am not so far entrenched that I cannot start developing each site as a standalone install. (Having started development elsewhere, I am having to rewrite all the multisite paths in content/db anyway.)

Here are the drawbacks that I see for a non-technical, non-Drupal client:

1. Risk of breaking sites when doing updates. (Updates can be tricky when they don't play nicely.)

2. Lax in performing updates, which will affect all of the sister organizations.

3. Confusion about paths -- Imagecache, WYSIWIG, content embedded.

4. Additional work required to split off a site, if one organization wants to host elsewhere. (Has already happened.)

5. Harder to maintain a duplicate testing environment, i.e., syncing databases.

Thoughts?