Your first scenario, does apply to reinvent the wheel, its self explaining.
The second scenario, does NOT apply if the existing code requires little modification, but if it does, its a good idea to try to use similar properties, methods, and usage than an existing code, so other developers doesn't have trouble using your "wheel".
Be careful by the "its always better to start from scrath" approach, it may take more time than you expect.
The third scenario you mention, its the "practical" approach. The "given wheel" may do the job, but, in reality, consumes too much resources, memory, speed, etc.
I worked once in an application that require to show hierarchical data in a treeview control from single table. We already have a control that could do that, but supported several tables, per item.
In order to use it, I had to learn too many stuff, assign too many properties, executes too many methods, and IT WAS SLOW. A coworker insisted on use it, in order to "not to reinvent the wheel".
I did a new control, from a scratch, read a single table, program only a few easy-to-learn properties. And before I knew it, there was another coworker that took it from the shared code repository, and replace the previous control.
Bonus:
When the wheel you already have is "squared". By "squared", I mean that in surface, looks like it does look like a solution to your problem, but after a good look, you get to the conclusion, that not.
It depends if you have the skills, and time, (and your company authorization),
to reinvent the wheel.