You really have two ways of processing quests : the configured way, and the custom way.
At the moment EQEmu "shines" in the custom way. I put shine in quotes because I hate Perl, but other than that it is very much open-ended
With the Perl scripts you can do a lot of things, it just takes time, knowledge and patience (did I mention "time" ?).
The other way is what wow-emulators provide : table-driven definitions to easily specify kill quests, loot quests, explore quests and a few others. The list is limited, the configuration tolerated is limited, but it is very efficient (in that the server handles it, and it avoids the silly Perl syntax errors).
Both can co-exist. The server can first check the "configured" quests, and then the fully-custom ones. At the moment EQEmu is lacking in the second option, which covers a big portion of the quest/task neeeds. If we had that, many "newcomers" could write their own basic quests, by tweaking tables instead of writing Perl. I am not only speaking of "Live"-like quests there, many custom quests would become very easy.
This is really what I was hinting at, that there are two parts in what you would like to implement, Derision :
* Exposing the functionality (opcodes) allowing the Quest Journal to work. Providing the functionality through functions in C++ and possibly Quest:: Perl function calls. This is the basis for task tracking.
* creating an "easy-quest" framework, using the requirements of the EQ Task system as a guideline.
You can have all those alternatives in a game :
* easy and limited quests with no tracking
* complex and open-ended quests with no tracking (as it is at the moment)
* easy and tracked quests (Quest Journal + Task system, what you are trying to achieve , and what basic wow emu supports)
* complex and tracked quests (what I am suggesting you enable by opening the Quest Journal implementation)
Not trying to scare you off there, but the task you have started encompasses all four, as adding the third one to the second one is close to enabling the four programming-wise. If your design is good you should get the other two as a nearly-free bonus. If not, well... You will still get the third one ! Just do not be puzzled when you realize the task you embarked on is tough. eh eh. The end-result will be awesome, but the price has to be paid !
At least that is my analysis of what is going on
I wish I could offer my help on this project, but I will be quite busy in the coming month. Still if you would like to submit some interfaces (function or quest:: Perl prototypes...) for review, some of us could find the time to provide some feedback. It is up to you.