This is about how you (the developer, or a team of developers) decide to model the problem (i.e., how you decide to view and represent various elements involved based on your understanding of the problem and the relationships within).
That means that the same example can be under different circumstances modeled in two different ways (e.g. in a racing game, the player model may be considered a part of the car model, and for the purposes of that specific game, it may not have an independent existence; in a game where you are normally on foot, but can use vehicles, they are distinct entities that sometimes may assume a "containment" relationship).
So, when reading various material online, don't focus too much on the specifics of the example, but try to understand the intent, and guess at some of the assumptions made based on the context, and based on what you know about composition and aggregation.
Let's go over some of your examples:
The path/segment relationship: Suppose you are creating some kind of drawing software, or some sort of animation editor, or whatever. While for the user there is no path without segments (and quite possibly, no free floating segments without a path), internally, you, as the developer, may consider a path to be an abstract concept, that contains segments that can be swapped, combined and manipulated in various ways, maybe even shared in order to achieve certain special effects (I'm making this up as I go along, by the way - I'm not saying this is the-one-right-way-to-do-it). So, for you, in terms of how the software works and how things are represented, they have an independent existence. You may even do things like have a null path (with no segments) that serves as a placeholder, or an empty segment container that you'll use later, or it could simply implement the path interface (with each method doing nothing) so that your client code could be written in a simpler way. Again, the user of the software may have a completely different view of these concepts; this is about how you internally went about solving the problem of representing paths and supporting the desired behaviors - i.e., how you modeled the problem.
car/wheel: Again, depends on the problem domain; if you need to be able to swap wheels, or track the car & the wheels separately (I don't know, maybe the software is for a vehicle repair shop), then model that as aggregation. If it makes no sense for what you are doing to allow the wheels to exist without a car, or even if the decision to not support that is acceptable and it simplifies the problem & the code, then model it as composition.
Note two things. First, you can choose to leave the ownership details unspecified and model things using generic associations, and that is perfectly fine; use aggregation and composition when you feel that the precise relationship between two model elements is important and you want to communicate that to other developers that may be working on the same project. Second, often, all these relationships will be implemented, in terms of language features, keywords used, etc., in the same way; it's the behavior, interactions, and the lifecycle of the instances that makes the difference.