These remarks are based on version: 2.80 (sub 74), branch: master, commit date: 2019-06-09 00:10, hash: 8452673a0189. See also gosgood-system-info.txt.

I have seen this here as well.

In working with an object with very simple geometry, and with a one hair particle system, it seems that child hair particles are previewed in the viewport as only first degree (linear) curves. There appears to be no mechanism to change this.

I surmise that the necessarily coarse character and poor approximation ability of 1st degree curves gives rise to @Mark Kenworthy (odysseus93) 's "expand-and-fly-off" description of the problem.

In particular, the Path Steps parameter and B-Spline checkbox appears to have no effect in 2.80. As a consequence, it is almost impossible to shape hair in the particle editor when the ratio of children to parents is about 6:1 or more.

As a workaround, check off Children in the Properties panel, Tool tab, Viewport Display and set Path Steps to a fairly high value. It is not a good workaround. One can only make limited judgements about hair shaping when just the parent particle hairs are previewed.

To reproduce:

1. Open hairsimple_280.blend. a. It contains one piece of geometry: Plane. b. A hair particle system modifies the object which has a particle edit data block. Only one hair particle has been added. c. Otherwise, hair particle edit and particle system settings are those as suggested by @Mark Kenworthy (odysseus93)

2. Find that it is in particle edit mode and the Comb brush is selected.

3. Comb the single hair. Observe: a. The underlying parent hair appears to be cubic; 2.80 renders this in black. b. The children are little more than staight line segments. 2.80 renders these in light gray. c. Attempting to adjust Path Steps affects only the parent curve; children remain as first degree linear curves.

4. Children of hair particles are also rendered as first degree curves in various viewport displays (workbench, cycles).

5. Only in rendering circumstances (F-12) do children of parent hair particle render as high degree curves.

In contrast, during editing sessions using 2.79b, child hair particles match the degree and rendering characteristics of parents. Only in viewport display in a 2.79b editing session, are child hair particles inaccurately displayed - but not as a linear representation, but as (apparently) cubics with seemingly incorrectly set control points, an ancient bug that is not at the heart of this matter.

The video clip bugreport_T65565.mkv depicts a 2.79b/2.80 side-by-side particle edit session using this sparse scene. The 2.79b session is on the left, the 2.80 session is on the right. hairsimple_279.blend was used for comparison with 2.80.

Ah, @Sebastian Parborg (zeddb) ! Welcome back to bug triage.
I disagree (a little bit) with your evaluation. There are Viewport side-by-sides near the end of video clip bugreport_T65565.mkv; Both the 2.79b and 2.80 viewport examples are both cycle-rendered previews and note that the 2.80 children are rendered as essentially first order straight line segments. My impression is that the issue is render-independent and I'm guessing differences in depsgraph evaluation in Viewport/render engine contexts is more pertinent, but I have not done any serious stepping through the code to substantiate that idea. Perhaps this weekend...

I'm talking about when rendering with F12. At least for me, it is only cycles that shows up correctly in that case.

The Bspline option does work. There is just a missing tagging, if you click the viewport it works.

@Clément Foucault (fclem) : Yes. That bit me in the posterior regions. I remember going over very carefully relevant parameters and remember looking at Strand Steps, changing it - seeing nothing happen. But, of course, I actually didn't kick the viewport display with a left mouse click. I made a little clip showing that it really does work, as you said - once a deliberate left mouse click was made on the viewport.

So taking everything into account I can't think this is a bug. Or maybe i'm missing something?

You're fine - not missing a thing. On the narrow technical content of this report, you are right: the bug isn't there. I'd vote for closure.
But mouse clicking in the viewport is still a PITA - a UI papercut kind of bug, methinks that's just going to confuse people. Should I open another bug report confined to just that issue?
Thanks for all your great work by the way - you and the rest of the crowd.

I also had this problem by watching this tutorial.
But when I adjusted the "radius" in the children tab, it got fixed

After reading this, is sort see the sluggish viewport still in 2.91 when your in combing mode and do edits. not everything seems to be updating properly. It was until i read this comment Garry R. Osgood stating, simply click in side the 3dv to "force" update it. I even downloaded files from this thread its either they are buggy for new Blender or its really blender viewport update issues. It took me many ticks and unticks to even get the children to show

Well tagging people just doesnt seem to go well. It tags the wrong person
@Garry R. Osgood (grosgood)