At least to me, the description is meaningfully different than "any other comment." In particular, the description is a living document that is expected to change over time as necessary such that anyone reading the task can just read the description and know what's up. (As opposed to have to read all N comments to know whats up.)

This notion of the description being all one needs to read to know what is up is particularly important for engineering efficiency - there is a nice, clean, agreed upon "spec" of sorts up the top, rather than each person reading and parsing all the comments and other updates to figure out what's up.

Overall, the description should be edited and its not unexpected for it to happen. Editing a comment however is a bit weird - its a digital version of a conversation, and we all know you can't edit the words you sent (...or the email that was sent from the initial comment, etc.) As such, I think calling out comment edit in the UI makes sense, but calling out the description edit is closer to UI clutter than utility. Further, when I play devil's advocate, I would argue that other summary fields other than description such as "Title" or "Subscribers" should also get this "updated" treatment. This seems bad.

I see, and having the option to use comment 0 as an "updated description of the task in one single place" instead of having to read 40 followup comments makes a lot of sense.
Might just be an issue of different social expectations and how much a reporter considers a task summary and description "her/his own". For example, I'd expect a MediaWiki user who started a discussion thread to be rather disturbed if somebody else edited their initial posting.

Now I wonder how to communicate ("warn"?) more clearly to Maniphest users that their initial comment might get changed by others over time.

I'm convinced by @btrahan's argument to wontfix this.

I think the problem of expectations in our community will be solved when Bugzilla users understand that the task description is not comment #0. It's the task description, it is not signed with anybody's username, and it belongs to the community. Wikimedia users know well this notion: in our projects, wiki pages don't belong to anybody either, and you can expect your initial big edited to be improved / messed / transformed by others.

If we have a problem of vandalism or edit wars we can restrict task editing in specific pages or projects, just as editors do in Wikimedia wikis.

btrahan:

In particular, the description is a living document that is expected to change over time as necessary such that anyone reading the task can just read the description and know what's up.

This makes a lot of sense, and done right, it could make the inevitable shifts in certain bugs over time more clear up front.

However, I don't see why that's an argument against having a clear 'Edited' marker. Wiki pages are also expected to be edited, but we have a visible history link. Perhaps, for UI consistency, there could be an unobtrusive 'History' link in all cases, rather than an 'Edited' only if they edited.

Further, when I play devil's advocate, I would argue that other summary fields other than description such as "Title" or "Subscribers" should also get this "updated" treatment. This seems bad.

It would be reasonable to do this (show other task-level edited fields history at top), but not essential.

In case anyone hasn't run into it, the fact that the description was edited is visible in the transaction log, and you can click the transaction to see a diff. I'll make a trivial edit after this comment as an example.

So we're recording this information and making history available (in general, for all fields), it's just not presented as a top-level marker, and there's no link to view the entire history of a field in isolation.

In practice, I don't think we've run into cases where this is insufficient. Most tasks have only a handful of transaction changes, and even for tasks with more it's relatively easy to pick out relevant changes. There's no real technical barrier to building more powerful transaction review tools (e.g., filter visible transactions to just edits to the task description) but I'd like to wait until the use cases are clearly motivated by problems actual users encounter.

On this install, when I make a major edit that changes the direction of a task I'll sometimes leave the original description at the bottom with an "Original Description" header -- see T731 for an example. This is a social solution, but I think it's better than stronger technical exposure of history because if that information isn't present the first half of the discussion doesn't make sense. It's arguably better to leave it there and just cordon it off than have a user start reading, realize "Edited" means "this task completely changed direction", not just "someone fixed a typo", and then have to go dig through history. (In practice, if we exposed this in the UI it would almost always mean "typo fix" on this install, and not be a strong signal of missing context.)

Generally, I think a change in this vein isn't totally out of the question, but it feels premature -- I'd like to see specific problematic user behaviors and figure out ways to address them. At least on this install I don't think I've seen any users making edits with unreasonable assumptions.