The pertinent info, to start with:
OS: Debian GNU/Linux 7 (wheezy)
----Java(TM) SE Runtime Environment (build 1.7.0_72-b14
----Java HotSpot(TM) 64-bit Server VM (build 24.72-b04, mixed mode)
CraftBukkit: 1.8.0 R0.1 (git-Bukkit-33d5de3)
RPGItems 3.0.4 (aka 3.4) by TheCreeperOfRedstone
Quests: First presented... not sure but I do believe version 2.0.0 of Blackvein; reproduced in 2.3.4 (build 65) and 2.4.0 (build 75)

The issue:
We use RPGItems to create items with recipes, nothing special, just a simple vanilla item with colored text. Now, Quests used to have RPGItems support, which might solve this issue if it were to be added back in, but nevertheless... What happens is that we set the Delivery item and then the quest will work for awhile before mysteriously ceasing to accept the items any longer. I apologize for not having the specific error handy, but it says something along the lines of "The item <display name | item ID name | quantity of items in hand> are not needed for this quest."

Things I've notice that may somehow play into the issue...

• 1. The quests.yml file does not store the display names as they are on the items. For example, if we have a stone block that is called "§c§lDecoded §6§lMessage" it will turn out looking like this (despite the odd fact that the Lore all gets stored properly with all it's formatting):

- name-PAPER:amount-1:displayname-Decoded Message

Note: This isn't exclusive to the Delivery Items, as the display name does not register as being colored when you set a custom reward that is also set via the "item in hand" (with a customized vanilla item, because we use the 'give' command for any RPGItem rewards)

• 2. RPGItems likes to sticks a ton of unneeded formatting code onto the front of the item. Which while all we might see is an orange [gold] and bold name called "Signal of Hope", the NBT data is actually showing this for the displayname "§0§0§0§0§0§2§7§3§7§l§6§lSignal of Hope". On top of that we've ran into instances where a recipe creatable item that is set to be a Quest's delivery item will fail to deliver if at the time the quest was created, the "item in hand" that was used is given by using the /rpgitem give . If at the time of quest creation the delivery item in your hand had been obtained by crafting it, the quest seems to work fine (at least for awhile longer).

The sucky part is this doesn't seem to happen in every case. For example, we have an RPGitem-created sword that has only a couple colors (it's set to invulnerable for durability I'm not sure that's the problem with durability turn-in, but not via Unbreaking NBT, just RPGItems internal method). The one quest seemed to not like accepting it, though we did manage to fix it, which if I can remember what exactly we did I'll edit to add that. Nevertheless, we then have a non-RPG created Nether Star with an insanely colorful name, in addition to a non-vanilla datavalue of 10 (reasoning: I found that this allows us to create unique recipes with RPGItems, without the datavalue changed these 'rare drop' variants in recipes can be replaced with a plain vanilla Nether Star). The weird part then becomes that Quests seems to have issues with the RPG created items, but has never had problems with that special Nether Star ¯\(o_o)/¯

Leaves me completely stumped, and the players perplexed as to why they can't hand in the items heh Doesn't help when it'll work when we first save the quest and we test it, but a few hours later it'll then randomly give a player problems.

Solution?
Since it APPEARS to be only an issue with RPGItems, so is it possible to tie into RPGItems again and access it's internal item IDs? (I call them the Raw ID, and is what you use in the 'give' command)
If we can simply specify the delivery item as being that RPGItem 'Raw ID' instead of a having Quests store a multi-tagged item name, it might avoid the issue... or at least I hope :\

Anything I can add, clarify or do to help by all means let me know!
Thanks for everything!
-Formula350

So, the issue is that displaynames aren't storing formatting codes? That specific error would indeed be handy!

I cannot see myself adding RPGItems support as the original plugin is dead and you're running a rewrite which hasn't been updated on Github since March of last year. but thank you for the detailed research & explanation.

Correct, the displaynames are not being stored with any formatting codes.

Also just to be clear, the 'error' is not a console error, but a message that only is displayed to the player via the chat.

As for RPGItems... I don't mean to pry, but given the fact that there used to be support for that once upon a time and that RPGItems has not changed any since the time when Quests last supported it, wouldn't it be possible to basically re-add that code? Alternatively, given that Quests does have an add-on feature, is there any chance of perhaps simply having that code shoved into an add-on instead? That way if it works, yay for me, but if it doesn't then there won't be any extra code to worry about.... 😄 Nevertheless, I do completely understand your reasoning, but you'd be surprised at how many people still use that plugin or try to use the old one (which ceased to work sometime in early 1.7, as people have commented to me on how they can't figure out how I'm managing to run it on 1.8 lol)

-Form

EDIT: Alright I tracked down the problem :\ So what happens is that when one of the three people on my server (myself included) create a quest that has a delivery stage that is a craftable RPGItem, we just use the command to give ourselves said item/s to have in hand. And that is where the problem comes in at, because for whatever reason the item you get when you are given it via RPGItem's give command there is a bunch of "junk format code" at the end of the first Lore line, but it is absent from the exact same item if you craft it.
Example (taken from NBTExplorer):
Obtained with the give command...
-Name: §0§0§0§0§0§0§f§e§6§lReplacement Beacon
+Lore: 4 entries
---§fBeacon Block Beacon§c§a§f§e§0§0§0§0
---§e§o"Beacon created using
---§e§ospare parts"
---§5Souldbound

Obtained from a crafting table...
-Name: §0§0§0§0§0§0§f§e§6§lReplacement Beacon
+Lore: 4 entries
---§fBeacon Block Beacon
---§e§o"Beacon created using
---§e§ospare parts"
---§5Souldbound

Unfortunately, we just have to try and remember to always craft the item 😞

However, I do feel that this is still a valid 'bug' because if another server happened to make an item that was obtained through >insert method here< and its only distinguishing feature was a colorful display name, for example §e§lVery §e§l§oFancy §e§lSword, when they create the quest it will only store as Very Fancy Sword; thus, Quests would accept a vanilla item that was simply renamed in an Anvil.

And for what it's worth, when you use the EXACT same method of adding the item into quests (holding item in hand, pressing 0 to use it), but as a Reward item. the Displayname formatting code is stored in quests.yml.