MacPorts recently added a feature ("rev-upgrade", now the default) where it would scan the installed binaries, after it had finished its work, and check if any of them would no longer work as a result of the upgrades that had taken place. It's intended to prevent an upgrade of a library from causing something else not to work. Mostly it is fairly effective.

However there is one case that it can't handle, which is dynamically loaded "plugins", since those are not visible to the loader until something in the application logic causes it to try to load them. Certain programs like The GIMP make extensive use of this feature. Which means that upgrades can still break those plugins. A typical break looks something like this:

dyld: Symbol not found: _UCNV_FROM_U_CALLBACK_ESCAPE_48
  Referenced from: /opt/local/lib/libwebkitgtk-1.0.0.dylib
  Expected in: flat namespace
 in /opt/local/lib/libwebkitgtk-1.0.0.dylib

Often the fix is to rebuild either the affected library (webkit-gtk in this case), or the thing it depends on, or both, so that they are back in sync. You can find the library containing the file reported as a problem with port provides, eg:

port provides /opt/local/lib/libwebkitgtk-1.0.0.dylib
/opt/local/lib/libwebkitgtk-1.0.0.dylib is provided by: webkit-gtk

Having done that, it's then possible to reinstall the port with:

sudo port upgrade -n --force webkit-gtk

Where the "-n" means "don't also reinstall every single dependency in the tree", and "--force" is the magic flag to force it to perform this action even though it is already installed and at the latest version (the man page implies that "-f" should also enable force mode, but in practice it doesn't seem to work with "upgrade", so you need the full word).

There is one more catch, which is that MacPorts also has a "binary" mode where it will try to download pre-compiled versions of the port from its binary archive. This feature has existed for a long time, but only recently seems to get a fairly high hit rate of binary downloads. If it finds a binary download, then the "force upgrade" actually works out to be "download and install again" -- but if the prebuilt binary has the problem you started with, that achieves basically nothing.

If necessary you can force a full source rebuild of that one port with the "-s" flag as well, viz:

sudo port clean webkit-gtk
sudo port upgrade -s -n --force webkit-gtk

which will make it ignore the prebuilt binary archive, discard any partially built source, and always build from fresh source, although obviously that'll take quite a bit more (CPU) time to do (especially with webkit and/or gtk!). (With this particular problem discarding the build directory -- port clean ... and starting again was very important, as the root cause was a build configuration issue; see below.)

Alas, after getting most of the way through this process with webkit-gtk, it turned out that this was a known problem with the Macports webkit-gtk, and the resolution was an update to the webkit-gtk build to activate an ICU patch which made webkit-gtk use the MacPorts built unicode support rather than trying to build against older Apple-supplied support. The actual fix was applied only about an hour before I started investigating the error when starting the GIMP. Had I known that in advance, what I'd have needed to do was:

sudo port selfupdate
sudo port clean webkit-gtk
sudo port upgrade webkit-gtk

to build webkit-gtk 1.6.3 rev 4, from scratch (rather than rev 3 which I had installed previously). And that also required building a bunch of other upgrades, so it also took a bunch of (CPU) time...

However despite the actual fix for this issue requiring a source patch, it seemed a useful thing to record for future reference (especially given it took a while to figure out again the right syntax for rebuilding a single port.) And of course to remember to search for the error message on the Internet before starting to diagnose it from first principles.