relative paths cause global plugins to load twice

I'm trying to create a portable MUSHclient with some global
plugins pre-loaded, so someone can just download and
run, then start creating worlds, and have it talk without doing anything else.

The problem comes when I try to turn the global plugin from an absolute path to a relative one. Here's what I'm doing:
1. Add a plugin, using omit_blank_lines as an example, to the global plugins list. Once done,
this turns into an absolute path, which I don't want.
2. Close mushclient, dump mushclient_prefs.sqlite, and change the PluginList preference to load
".\worlds\plugins\omit_blank_lines.xml".
load it back in, and restart mushclient. Checking the global plugins list,
it says .\worlds\plugins\omit_blank_lines.xml - so far so good.
3. Create a new world, and save it. This also works fine.
4. close the world, and open it again. This time, I get an error that says omit_blank_lines
is already loaded.
Looking at the .mcl, the plugin shows up in the plugins section when I use a relative path for the global plugin,
but not when I leave it alone.

What is your preferred solution here?

1. Comparing plugins for working out whether to load a global plugin compared to a local plugin, should both use absolute paths? OR
   
2. Attempting to load a plugin which is already loaded should silently fail (ie. do nothing, the plugin is already there).

I believe this is similar to the problem I had in this (solved) thread:
http://mushclient.com/forum/bbshowpost.php?bbsubject_id=11058

As such I vote for option 2.

Looking at the code Fiendish it's not particularly simple. By the time we get to discovering the plugin IDs are the same we are half-way through creating it, memory allocated etc.

But I suppose if the duplicate ID can undo all that, it should be able do undo it without the error message.

Allowing plugins of the same name to silently be discarded was too much complicated work. Plus I don't like the idea. It's like having if you delete a file, and if the file does not exist, not getting an error message. I suppose the end result is the file isn't there, but attempting to delete a non-existent file in the first place should be an error.

Fixed the reported problem here in version 4.74 by tightening up the check for whether plugin A is the same as plugin B by converting both pathnames to absolute pathnames internally.

It seems like this depends on perspective. From a consequentialist viewpoint, if I call a deleteFile function, very probably all I care about is that the file doesn't exist after the function call. I don't care about the state of the file before the function call. It serves me better for the function to be a no-op if it doesn't exist in the first place than to blast an error at me because my desire is only to have the file not be there. At least function calls tend to return error codes that you can then choose to ignore, which is not the case here.