First, allow me to say that your findings are very promising. A good Quest Journal was really a missing part of EQEmu (and in fact of EQ for some quests).
I did not play with the task system very much on Live, it really came when I was taking a break from the game. There is one thing you should be careful of : may be some Live tasks have simultaneaous activities. Something like "Make 7 flame Posts" and "Get banned for one week", that you need to complete before you can progress to the next activity. As you see I am sticking to your examples spirit
Regarding the design, you could make the Quest Journal have even more reach by separating the low-level Journal handling from the Task system. In short, it could allow quest designers to track quests in the Journal even for quests that are not formatted like tasks. Let me take an example, this time from a quest idea I actually started implementing through the normal Perl system..
"The young gnome had been playing a few pranks to several personalities in Ak'anon, following the directions of the enchanter guild mistress. The last one had put him in hot waters though : passing for a half-elf had been easy with the illusion spell the enchantress had given him, but he was still shaking about the thought of what would have happened had he answered to the necromancer in the wrong way. But the real problem was : what to do with the letter the necromancer asked him to deliver to the dark elf necromancer guild master in Neriak ! Clearly he had gotten more than the enchantress had hoped for, surely she sent him there on purpose, not just to play one more prank. He could certainly bring the letter to her, or may be actually delivering the letter to its actual recipient would make him rich. Neriak was a wealthy city."
At some point the character can choose one of two major paths in a quest. Having the Task Task system handle that could be tricky. Handling arbitrary quest progress triggers (like we do in Perl sometimes) would be overkill. It is made for simple tasks and let's face it, many quests are like that. On the other hand it would be very nice to allow regular Perl quests to benefit from the Journal, given the quest writer accepts the extra work naturally.
You could achieve that by untying the actual quest progress (task progress) from the Task system logic. The tables would be unchanged, except the comment for completed would not apply : for arbitrary quests donecount has no meaning. The activity would be complete when the completed field is filled.
What does actually change then ? Answer : the way the tables are managed. At the moment may be you are thinking of wiring the table management into the task system. Instead you could separate the table management, and expose all "atomic" operations on those tables as quest:: xxx calls in Perl scripts, on top of using them for the task system of course.
Quest writers could then decide when to :
* quest::start_task(taskid, activityid) : the quest could start at any activity, defined by the Perl script
* quest::complete_activity(taskid, activityid) : completed date set by the server
* quest::start_activity(taskid,activityid) : this activity is started. Several activities could be up at the same time.
* quest::complete_task(taskid) : completed date set by the server
Of course those "manual" activities would not track progress , the Perl script does. But the player would at least see the quests he is on and the text for the current activity.
It would be the quest writer responsibility to start the next step(s) after completing the previous one(s), to detect when an activity is complete etc. A few checks could be added to avoid inconsistencies, like tasks completed whereas some activities are not complete for this task. But the code need not ensure an open task has an ongoing activity. The Perl scripts pilot the Quest Journal, and try to reproduce faithfully the facts. The Task system in this case is not active. With an activity_type of "Unmanaged" or somesuch it would be easy to deactivate the task system for those "quest" tasks and activities.
Ultimately this could lead to a flexible, semi-automated quest/task system : quests/tasks and their steps would be defined in the DB, with the transitions from a set of steps to the next ones. Each activity/step could either be handled by Perl, disabling any automated counting of objectives, or be fully supported by the engine for easy activities (loot, kill, explore). This would just depend on the activity_type. But it can be built one step at a time
By doing that we could have an emu better than Live with regards to quest tracking : even old quests could be tracked by the Quest Journal, given they are reworked of course.
I suggest this because I doubt it would be much more work to structure the code to allow the Task system to be optional with regards to the Quest Journal. Most of the things to write are the same, you just need to let the Task System pilot the Quest Journal, not intermix them and make them dependent on one another.
I hope this did not read like gibberish