As Ted mentioned, for both of your examples, the sets of line segments have overlapping measures that will cause the 1 meter line to fall inside of a 2 meter line. Since all your lines are the same color and thickness and no end markers, there is no way you will ever see the overlapping lines as separate features, but they are actually there, whether you see them or not. It appears you have select both segments so that again only the longer one is visibly highlighted. To demonstrate that you actually have a real problem you need to filter out the 2 meter long segments by using a definition query like:
to_KP_km - from_KP_km < .0015
If the 1 meter lines still don't show then the problem is real. But if they do show up after applying the filter then this is simply due to the fact that you are obscuring the 1 meter lines by overlapping the segments.
To use symbology to show that there are actually 2 lines of different lengths that share a segment without using a filter, you would have to add end cap markers to the lines, and use a categorized or proportional symbol that varied the line colors and thicknesses according to the line lengths. I would change the values in the Length_M field to be correct (since they are not correctly reflecting the measure lengths for the 2 meter long lines) and use that to vary the symbols. Additionally, to ensure the lines draw in an order where thinner lines draw on top of thicker lines you would have to do a decreasing length sort of the event table so that the shorter events draw last on top of the longer events, or use separate layers with different definition queries to make shorter lines draw last in the top most layer.
I am not clear what this data is showing or why you would want to create overlapping segments. Most event tables do not contain overlapping events for one attribute type, like speed zones or lanes, unless there is a right and left hand offset to separate the overapping line types. If a left and right hand offset applies then there is a setting to use a numeric field with positive/negative values that will offset the lines left and right so that they do not overlap. Below is an example where I use different symbol categories from two fields to separate overlapping line types using color. Another field is used in the event layer set up to control the left and right hand offsets. These lines represent house number address range data patterns for each side of the road. The side offsets were determined by the position of the actual address point relative to the central lines (the Centerlines are not being shown in this example, only the offset lines). The thicker lines are highlighting unexpected addressing patterns between house pairs with the same types of Orientation and Parity and the events were actually sorted according to their category and measure values to display them in a specific order. The order of the Symbol Categories in the layer symbology list also affects the order in which the lines are drawn, so technically I should move the thicker lines below the thinner lines in the symbol list to get the thin lines to always draw on top of the thicker lines wherever an actual overlap occurs between two different categories.