It seems like xffm has three different methods for determining file type. First, when it shows the icon and builds the context menu for a file, it has a decent way of determining what type it is just by extension. When you go to "Properties" in the context menu, it uses some other (and I'm guessing slower, because it only needs to work on one file at a time) method to figure out what type it is without the correct file extension. When you open the file you would expect the program associated with it to be determined by the second, more accurate method. But it isn't. For this action, as far as I can tell, xffm uses a completely different and very broken way of guessing what type of file it is based on extension. It thinks the extension of "Mr.Bill.jpeg" is "Bill.jpeg" instead of "jpeg". So I can't easily open any file that has more than one dot in its name. The first method does not ever make this mistake. xffm will show the jpeg icon for "Mr.Bill.jpeg" and even get the "Preview this image" in the context menu. But when I double-click, xffm is stumped. It's very clear to me that this mysterious third method needs to be dumped, and xffm should open a file using the same type-guessing method that it does for the "Properties" dialog for accuracy, or perhaps the directory-listing method for consistency.
The faulty behaviour you describe is fixed in branch 4.1, unfortunately it is not possible to backport to the 4.0.x branch due to time limitations. If you find any anomalies on file association with CVS HEAD, please reopen bug report with details for 4.1.