That's a lot of words, but I think it boils down to: you're making an assumption that two calendar events with identical naming and identical time entries will always have a desired behavior of being deduped.
- Maybe you want to separately invite people to the same thing and have different descriptions, now you're increasing the number of things to equate.
- Maybe a user creates one event that is simply a title and a time, and they then want to create a second one for another purpose. However, it keeps getting deduped and they don't know why. Now you have a user education problem that you have to solve.
- Now you might think: well just make it a toggle in the settings! Okay well now you have to add a new setting and that expands the scope of the project. Do you make it opt-in or opt-out? If it's opt-in, what if no one uses it? Do you maintain the feature if there's a migration? If it's opt-out, you still have the above problems.
I could go on. And this is mostly an exercise of not underestimating a "simple" change. Calendars (and anything involving time) in particular can get very complicated.
- Maybe you want to separately invite people to the same thing and have different descriptions, now you're increasing the number of things to equate.
- Maybe a user creates one event that is simply a title and a time, and they then want to create a second one for another purpose. However, it keeps getting deduped and they don't know why. Now you have a user education problem that you have to solve.
- Now you might think: well just make it a toggle in the settings! Okay well now you have to add a new setting and that expands the scope of the project. Do you make it opt-in or opt-out? If it's opt-in, what if no one uses it? Do you maintain the feature if there's a migration? If it's opt-out, you still have the above problems.
I could go on. And this is mostly an exercise of not underestimating a "simple" change. Calendars (and anything involving time) in particular can get very complicated.