As in many other parts of Blender, it'd be a good idea to follow the standard ordering + grouping of includes (e.g. have all includes from the same module/with same prefix together). Doing so makes it easier to see what files you've included (avoiding duplicates), and also often helps avoiding include-order problems.

Use the defines/functions from our standard math library instead. See source/blender/blenlib/BLI_math.h

See BLI_utildefines.h

There should be existing equivalents for most of these functions in the BLI_math math library already. For anything that isn't it might be worth submitting a separate patch for review with just those changes, and assign to campbell or brecht.

Use the GPU_point_size() and GPU_line_width() calls instead. We're trying to deprecate the direct use of OpenGL calls so that in future we can introduce other backends (e.g. for Mac)

elif does this code compile right now, or is this just WIP or using some macros?

Use NULL for pointers. Only use 0 for ints (and 0.0f for floats)

It's better to have each group of flag/defines done using named/typedef'd enums, so that you can note in a comment beside each field which bunch of values/defines can be used with each property. This reduces the chance that the wrong values/defines get used with the wrong fields.

What's this for?

Typo - use_different_style

What's this?

Runtime data shouldn't be saved into SDNA structs directly. The current convention is to have a _runtime struct for runtime-only data (e.g. see the Object_Runtime struct in DNA_object_types.h).

From the looks of things, it may be a better idea here to do the following:

1. Move all the DRWShadingGroup, Gwn_Batch, and any other runtime-only stuff to a separate struct (e.g. LANPR_LineLayer_Runtime), that's defined only in some of the LANPR draw engine headers (in source/blender/draw/...`).
2. In this struct (LANPR_LineLayer), have a void *runtime_data; pointer that points to the instance of LANPR_LineLayer_Runtime used for this layer

snake_case only

Use another name for this.

1. It may cause issues with the makesdna parser - Most likely it's fine, but this could still reveal some hidden bugs there.
2. It's too easy to confuse this with the other size field (1471)

There's no need for the icons here, especially if you're only going to set them to all be the same

At some point, it would be good to get feedback from the UI team (@venomgfx and @William Reynish (billrey)) about the names/labels used in the interface. Currently, it's unclear to most users what "DPIX", "Snake", and "Lanpr" mean. But this is all stuff that we can easily work on.