The new bug:
On OpenSim with XEngine, you can use “dummy” (or any other dummy name) as the texture in a call to llSetLinkPrimitiveParamsFast(link,[PRIM_TEXTURE,"dummy",... and, for example, rotate whatever texture is already there. But under YEngine the texture stands still and the rotation does not work.

Background:
There are some flags in the rules list to llSetLinkPrimitiveParamsFast which require that you send a bunch of parameters at once. For example, PRIM_TEXTURE requires that you send the texture again, the repeats vector again, the offsets vector again, even if all you wanted to do was change the rotation of the texture. In SL, if any of these failed, the internal code would move on to the next and it would be given a chance to work. Sending a texture of NULL_KEY should have allowed you to rotate a texture in place, but this did not work in OpenSim. Instead the texture would be replaced by a dark gray. I discovered a long time ago that I could use a texture named “dummy” in OpenSim and as long as there was no texture in the inventory of the prim with that name, the PRIM_TEXTURE call would proceed and the rotate argument to PRIM_TEXTURE would successfully rotate the current texture on the prim without changing it.

An aside:
You would think that the correct thing to do would be to call llGetLinkPrimitiveParams to read the texture and other parameters, modify the rotation, and Set it back again. This will work when you test it yourself, but when you give the resulting object to anyone else it will FAIL! It fails because you have permission to read the UUID of your own textures, but your friends (or you customers on the Kitely Market) do not have permission to even know what the UUID is of the texture is. Then the script fails to work right.

Another aside:
You would think that another correct thing to do is to put the texture in the inventory of the prim and mention it by name in every PRIM_TEXTURE call. But many merchants on the Kitely Market don't want to give away copies of their textures. They just want to put them on the surface of things but not in inventory. And sometimes you are not the owner of the texture on a prim you got and you cannot put a copy of it in inventory.

Steps To Reproduce

Create a prim, put a texture on it that you will be able to tell when it rotates. Put the following script in the prim. Under XEngine, you will see the texture rotate like a backwards second hand. Under YEngine, the texture will not rotate at all. Experiment with the different commented out versions of the call to see what else goes wrong. For example when you use NULL_KEY, the texture turns dark gray.

You are correct, I was comparing XEngine from last month to YEngine today. I updated my XEngine region to the same recent binaries and now I get the same results with either script engine.
HOWEVER, I am now getting a result that is different than older versions of OpenSim (before the 8517 fix on April 18) and different from SL.

In PRIM_TEXTURE calls in older versions of OpenSim:
NULL_KEY replaced the texture with a dark gray
“” left the texture alone but allowed other parameters to work
“dummy” left the texture alone but allowed other parameters to work

In OpenSim after April 18:
NULL_KEY leaves the texture alone but allows other parameters to work
“” leaves the texture alone but allows other parameters to work
“dummy” causes PRIM_TEXTURE to abort and fail to execute the rest of the parameters

So the NULL_KEY behavior is a nice addition, but aborting on missing textures breaks a feature of OpenSim that I have used in many scripts. I had assumed there was no difference between “” and “dummy” and used “dummy” as documentation in my code to show that I didn't want to change the texture.

I went to SL and performed all the experiments again with this result:
NULL_KEY replaced the texture with dark gray
“” replaced the texture with dark gray
“dummy” replaced the texture with dark gray

The SL Wiki has this caveat to say about the texture argument:
“If texture is missing from the prim's inventory and it is not a UUID or it is not a texture then an error is shouted on DEBUG_CHANNEL.”
I saw no errors but may have missed them. I just saw dark gray textures result.

The Wiki goes on to say:
“The following constants can (optionally) be used for the texture value: TEXTURE_BLANK, TEXTURE_DEFAULT, TEXTURE_MEDIA, TEXTURE_PLYWOOD and TEXTURE_TRANSPARENT. ”
NULL_KEY is not mentioned in the Wiki (I'm looking at page http://wiki.secondlife.com/wiki/PRIM_TEXTURE [^])

I have never seen the behavior in SL or OpenSim of NULL_KEY leaving the texture alone, although I would welcome that as an addition. I have never seen SL do this behavior described by ZauberParcelsus in mantis 8517. I think the nice behavior on missing textures is a feature that was added (perhaps inadvertently) to OpenSim. I would welcome the addition of NULL_KEY but please don't break the behavior on missing textures.

Just reverted to old versions behavior as you request.
Invalid or not found texture ID/name (including "" and NULL_KEY) should again do the other parameter changes not changing current texture.

older versions of opensim did split this command in several subcommands. (3?)
each of those commands did somewhat heavy decode and encode of all textures face data from/to binary form and few more things.
A error on the texture ID/Name change was ignored.
A few months ago I did change that, so there is only one decode/encode stage, updates etc.
Doing that I did cause this differences making a error on the texture id/name abort the entire command, more close to that wiki.
But no really need to try follow that now, specially when that does not match inworld behavior

I pulled a new copy and tested it. I like the new behavior: A texture of:
NULL_KEY leaves the texture alone and executes the other parameters
"" leaves the texture alone and executes the other parameters
"dummy" leaves the texture alone (unless there is a texture in inventory named dummy of course) and executes the other parameters

So now ZauberParcelsus and I are both happy, all our old code works. It is not the same as SL, it is better! Go OpenSim! I'd call this mantis and 8517 closed.