Are you using different correlation tokens for each task?

My initial thought is that you're trying to use the same account to test
this functionality that you used to install and secure the Central Admin
app pool. Is this the case?

That's probably the case. Currently the identity in of the Central
Administration pool is set to Network Service. From what I've read
after seeing your comment that's probably not correct. I see it's
supposed to be a domain account, but I can't seem to find any
specifics. Does anyone have some guidance on what it should be?
Also, are there any other places where the default service account
should be changed?

Make sure the app pool account is not the same account as the one that
was used to install SharePoint. Ensure this account has db_security and
db_creator permissions in SQL and is a member of the local admin group
on the WFE server.

And then ensure that you're logging in with a different account that is
a member of the farm administrator's group.

Ok, I re-built our installation from scratch, with the below
suggestions. The Central Admin pool is unique, has db_sec and
db_creator permissions set in the db and is a local admin on the wfe.
The SharedServices app pool identity and the main site app pool
(sharepoint - 80), however, are sharing the same identity (I don't
know if that's a problem).

Anyway, the problem  is the same as before: Approving a task  in a
workflow where task approval controls content approval results in a
new, identical, task being created by the sharepoint  "system" account.

Someone mentioned something about using unique tokens but I'm not sure
where that even applies. I'm not designing a workflow  just using the
built-in approval.