Hi there, I can't speak for your specific problem, but after much angst I got XML transformations happening in OJS 2.4.1. I do believe we sent the patches off to OJS but can't find anything to that effect ...
I can't give you access to our repository for the modified version of OJS we use because it contains all of our journal configuration (which I'm busy separating so I can release our changes as per the GPL), but I've attached the modified xmlGalley plugin we are using.
* It's a customized version of the 2.4.1 version and not the 2.4.2 you are using
* the xmlGalley plugin felt like it had been neglected for a long time when I found it.
* you will need to add a new entry to your config "xml_transformation_cache" under the "cache" heading. I have this set to true for production environments, false in testing/dev environments.
* you will need to point "nlm-xhtml.xsl" in the "transform/nlm/" dir of the plugin to your xsl stylesheet. And by 'point' I mean a symlink, which might be foreign to you if you don't run *nix. I'm not entirely sure what I've done here, but I seem to have it pointing to our customized xsl (not included). you could totally point it to the one that comes with ojs (which I've renamed "ojs-nlm-xhtml.xsl").
* the plugin also fixed another bug where view counts were not being counted because it would hit the xml galley detector first, get handled there and then skip being incremented because the plugin returned true or something to that effect.
Hope this is a little useful.
Now - I don't suppose you know anything about this bug (which is how I found yours
[12-Dec-2013 12:23:53 UTC] PHP Fatal error: main(): The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition "ArticleXMLGalley" of the object you are trying to operate on
was loaded _before_ unserialize() gets called or provide a __autoload() function to load the class definition in /var/www/vhosts/foojournal/httpdocs/cache/t_compile/%%28^280^280EE005%%dublincore.tpl.php on line 67