Event handlers configuration settings best practices

Where to place configuration settings for event handlers?
I have thought about it and came up with a few options:

Place config information in the event handler registration info
Every time you register an event handler with a list you can specify data specifically for that registration. This can be done with a feature, or using code (see my utility pack for an easy way to do that)
PRO:

1. Can be deployed using a feature. We can have different config per list.

CON:

1. We only have a seperate config per list (no one place to manage all lists).
2. Limited to 256 characters.
3. You will need to run code to change the configuration.

Place config information in the web.config <appSettings> section
I was surprised to find that the event handlers get access to the web.config as if they were web applications. Cool!
PRO:

1. One place to manage per web application. can be deployed using a web application feature and some custom code (http://blog.tedpattison.net/Lists/Posts/Post.aspx?ID=4)

CON:

1. Hard to deploy every time you create a new web application in the farm. This can be resolved by creating a feature and stapling it at the farm level (scope is webapplication) that modifies the web.config to include the section you want, and setting some defaults - so that the event handler finds what it is looking for when a new web application is created.

Place config information in a settings file on the file system
PRO:

1. One place for the enitre farm, can be deployed using a solution package

CON:

1. Location is hard coded in the event handler (unless we use this approach mixed with option one!).
2. Folder must allow users to read, or impersonation will be required.

Place config information in a settings file in the GAC, next to the assembly
I used this a few times. You can put a file right next to the dll, and use a helper class in the dll to deserialize it and read the values.
PRO:

1. one place for the enitre farm, no hard coding of location.
2. Use Mide Woodring's AssemblySettings class to read from it. can probably be deployed as a farm feature

CON:

1. Every time a new dll version is entered, the config will be deleted and will have to be added again.

Place config information in a document library\list in the root sharepoint site of a site collection or in the central administration site or the shared services site for that web application
PRO:

1. Deployable as a feature at the site collection level

CON:

1. still requires custom code to get the config.
2. performance hit on reading the configuration (can be minimized with caching).
3. (if root site collection option) Only supports site collection level configuration.

Special thanks to Reza Alirezaei who pointed out some spelling mistakes and commented on the web.config section.