I would strongly recommend that you take Scott's advice. In relational database terms what you have is a binary many-to-many relationship type between tasks and statuses. CompletedDate is a non-key attribute of the relationship type. Such a relationship type should be modelled in one way only, which is by means of a table which resolves the relationship type into two one-to-many relationship types. In addition to the two foreign keys the table can have non-key columns which represent attributes of the relationship type.
The important thing about modelling a relationship type in this way is that it scientifically mirrors the way in which the two entity types, tasks and statuses, are related in the real world with which the database is concerned. Fortunately we don't need to concern ourselves with the relational algebra in which the science is expressed. The point is that it is science and therefore subject to formal and immutable rules. The bottom line is that if the database models the reality as a mirror of the relationships in the reality, the database can be relied on to behave in the same way as the reality, and we won't suddenly find that the database contradicts that reality and presents us with bad data.
If you want to familiarise yourself with the process of Normalization you might like to take a look at Normalization.zip in my Dropbox public databases folder at:
https://www.dropbox.com/scl/fo/0scigd3r48hx5xrev2jrf/AB0-GMdTgMAO5O1cGdr3QW0?rlkey=ib6bs6g9jqcrywwzivur3265t&dl=0
This little demo file provides as simple as possible, but no more so, an introduction to the subject. Don't concern yourself unduly with the formal definitions of each Normal Form, but try and gain a good understanding of the first three Normal Forms to start with, and how these govern good database design.