This took awhile, but I found a very odd bug in the part of the replacement routine that swaps out old paths with new ones in the body of posts.
In filefield_paths.module, like 511, we have this:
$file['filepath']['new'] = str_replace($file['filename']['old'], $file['filename']['new'], $file['filepath']['new']);
However, at this point, our $file['filepath']['new'] should already have the new filename, from earlier, line 502.
What then happens is, if the original filename was unchanged, a second replacement is performed on the original filename, doubling up and invalidating the filename placed in the body.
To put this another way:
1. I enable filefield_path, and set a replacement pattern like: [nid]-inline-[filefield-onlyname-original].[filefield-extension-original], apply strtolower, pathauto, etc.
2. I upload a file named "sample-file.jpg". This file's name will require no processing, since it's already obeying the rules.
3. I insert this into the body, like src="files/inline/sample-file.jpg".
4. The replacement routine kicks in, changes it to "files/inline/123456-inline-sample-file.jpg"
5. The logic on line 511 then does another replacement, giving you "files/inline/123456-inline-123456-inline-sample-file.jpg"
I was able to resolve my issues by simply removing that line. That's what the attached patch does.
What I'd like to know though, is, was this logic intentional? Or was this perhaps something that should have been removed from some previous iteration of this module?