strange timequest report

This is what I think is happening in your design: You've had threads with a clock created by a divide-by-2 register. (I hope you checked out my posts that I referred you to with caveats for creating clocks that way.) I suspect that the register, which has a name ending in "OUT_STROBE", is a divide-by-2 register driving the clock signal constrained by the clock called "OUT_STROBE". If so, you have a clock-as-data-analysis situation. If the same signal is used as both a clock and as a data signal, the reporting can be confusing. A report like yours is given for the feedback path with the divide-by-2 register as both source and destination. The feedback path is a data path for the same signal that is used as a clock for other registers. That results in the confusing reporting for clock-as-data analysis. TimeQuest does it the way it does to be consistent with PrimeTime (as I understand it).

This is the first possibility I thought of, but it probably isn't what you have in your design: The same register can have more than one clock. An example is a register with clocks selected by a mux. Unless you tell TimeQuest otherwise (typically with a set_clock_groups command), TimeQuest will assume that one of the mux input clocks can be selected at the time of the launching edge and another mux input clock can be selected at the time of the latching edge.