In the article
http://www.novell.com/communities/node/3463/upgrading-driver-configurations-idm-35
Aaron Burgemeister addressed one issue of the question (and addressed it well!) but did not talk about the second issue, which was:

"If we overlay the policy configuration files to exploit the new architecture, is that where the potential risk arises?"

The answer to that is Yes - if you overlay the 3.5 sample configuration files on top of existing rules you have customized, then all sorts of things can happen. I started a call for comments about what you need to do add the functionality from 3.5 to existing 3.01 rulesets in this article:
http://www.novell.com/communities/node/1478/

I found at least one thing you need to do with the Lotus Notes driver for proper Notes ID file password changing in this article:
http://www.novell.com/communities/node/1521/

And I found an issue to watch out for with the AS400/i5os/Midrange driver (Bi-directional version, not fan out), in this article:
http://www.novell.com/communities/node/1591/

If you find any more, it is important to get the info out there and posted! For a collection of tips for upgrading to Novell Identity Manager 3.5.x, see http://www.novell.com/communities/node/1478/

The best way to figure this out is to try it, break something, figure out what broke, fix it, document it, and then let everyone else know about it!

The Problem

The basic problem is that once you customize one thing in an existing rule, you can no longer just overlay the next driver configuration. In reality, there is probably no way for Novell to solve this issue, either. You could approach it by making sure that every change you make is handled by a new Policy object with your own naming structure. That might mitigate it, but you need to re-evaluate what the default rules do after each release to confirm that nothing unforseen has been changed that could affect assumptions you have made in your rules.

The break and veto actions are perfect examples of how this might affect you. If your new policy object is linked after existing ones, but in the next release they add a Break or Veto action into the preceeding rule, then of course your rule will never fire.

The nature of Identity Manager's design model is that this is going to be an ongoing issue, and you basically MUST have an automated/scripted test environment set up to validate your work. That way, any minor change you make can be tested with confidence that nothing broke.

There are tools out there for this, such as TriVir's IDMUnit (http://www.idmunit.org). Other people have used the eDirectory ActiveX controls and LDAP tools to build automated testing scripts in Excel spreadsheets to do this. You could also use an LDIF in a script that makes a series of changes (modify a password, modify a name, move an object, delete an object, etc.) and apply it to each connected system that can respond to LDAP. Then use another script to query for the expected results and post success or failures.

This gets more difficult as the number of connected systems grows, because LDAP only gets you so far in terms of systems it can talk to (eDir, AD, Lotus Notes (sort of), perhaps others). But it is a good start!

Standardization

With the development of the Novell Identity Manager Resource Kit (discussed at a session in Brainshare last year by Volker Schrieber) Novell is internally pushing the driver developer teams to standardize a lt of naming things inside drivers. Examples include a common naming model for Global Configuration Values, and assumptions you can make that there will be a Default Users container GCV named something standard for your driver to consume. This way, the end user would only have to change the value in one place, and all drivers could use it. What is kind of neat in that the way GCV's work is that the local driver GCV overrides the Driver Set GCV, so exception handling works perfectly well in this model! Every driver users active.users.acme, except the Mainframe driver, which needs to use Mainframe.users.acme container. It's easy to handle this exception.

Other ideas are starting to show up, such as more standardized naming for default policy objects that are shipped with drivers. No more objects named "Placement" or "Creation" - instead, they will be named "sub-ad-cp" or the like, for Subscriber channel in the Active Directory driver Creation DirXML Script policy. (My personal policy has been to rename the shipping rules to sub-placement or the like, within a driver set.) This will allow you to know information about the policy object just by looking at its name. Some of the drivers in the Identity Manager 3.5.1 release have started using this naming model. Others will follow, I imagine.

Upgrading

What I am curious about is how Novell will recommend that we "upgrade" existing drivers to this model. I cannot see any other way than by hand. One possible approach would be using Designer to compare two existing drivers, which is not officially supported at this time. People in the forums have requested this feature, and we shall see if it gets added.

An interesting approach suggested in the forums is to "fake it" using the existing tools. For example, you could use either an existing tree or a test tree inside a Virtual Machine. Then you would take your existing production driver and export it to an XML Configuration file. (You are doing this to backup your configurations before you make changes already, right?) Then import this into either your test tree (or production as a second driver set, just don't actually start it), then import the default driver with the exact same name into your Designer project. When you run a compare in Designer, it shows you the differences between the two configurations.

This is not perfect, as it is hard to store that set of differences or print or whatever, so that you can work on it item by item. But it is a beginning! You can at least start to work on the issue via this approach.