Another suggestion is to not import layers from DXF that are hidden or/and not printable. Or specify layer(s) to import drawings only from them. Now I need create a copy of DXF and manually delete unneeded layers.
I noticed what points from DXF are not able to import to KiCad. Maybe they should appear as small circles or something like…
I think DXF has simply borrowed code from LibreCAD, and whilst it does work, it has a low IQ.
As you say, some layer smarts would help greatly, & I think a layer-MAP system, would allow better control.
ie, right now, DXF imports to only one user-choice layer, but there are many layers in the list !
If DXF were able to (optionally) simply map Named layers to kiCad layers, that would allow one DXF import to multiple layers ( eg Edge.Cuts & Dwgs.Usr) for example. F.Cu should be valid too.
Also, DXF import is fragmented/exploded, with no preserve of polylines or fill, or width,
so I cannot see a way to do
DXF -> Zone,
even though the DXF has all the required closed polyline information.
For now, you need to do as described, and used a companion 2D CAD pgm to filter DXF info.
At the moment all width is imagined to be 0 and assigned whatever the kicad line default is. Until a few months ago even the units weren’t properly checked.
Filled regions introduce all kinds of problems and more specialized code is needed to handle them well. Perhaps one day in the future when we have a well-defined API for pcbnew we will be able to rewrite the DXF importer. For fills we need to (a) assign a net name or specify no net, and (b) handle region growth correctly if the boundary width is not 0. For (a) we cannot simply give a default because that would be a convenient method to introduce design faults and for (b) we might need an improved geometry kernel. Either way, I imagine DXF improvements will have a very low priority so unless another developer comes in and makes changes then nothing will happen.
I also found this interesting work, but for footprints, which seems to use a external python DXF parser
https://pypi.python.org/pypi/dxfgrabber Code
https://pythonhosted.org/dxfgrabber/ DOCs
I can understand the complex end of the scale, but maybe there are small steps that can be taken ?
eg a tickbox could allow Widths inside DXF to be imported, or even a DXF-local-default width that can be different and more obvious, than KiCad default width.
Currently, in kiCad Layout there is no means to select many line-elements and edit Width.
I can select-many and Copy, but cannot change Width.
Those two effects conspire to make importing DXF-tool-paths for example, much harder than they need to be.
Likewise, net-name can be given a default in the DXF import form, and edited later.
At least this gives a place-holder, that kicad can leverage off.
Fill support would need polygons to be preserved, not exploded into line segments.
Again, here KiCad allows multi-select and Copy/move but no edit.
Also, KiCad does not allow easy jump between polyline entity - they are very similar in the DXF and Kicad_pcb files, but Fill and Keepouts cannot be inter-changed - eg if you import zones via DXF, and they arrive OK as closed polygons, but some are Fill and some are Keepouts, it is easier if you can select/retype inside kicad.
I would sidestep the complex region growth issue, by applying the rule that DXF Zones are outlines 
ie to me DXF can expect to know about X,Y,LW,LayerName & of course Line/Polyline but any region growth is managed inside kicad by a later line width change (possible now)
If you have a good idea of what you want done and can describe the desired improvements and how to address related issues, you might try to post to the dev list to see how people respond. At the moment so few people seem to use DXF (or very few bother to comment) that many items which I consider bugs remained unreported and were only fixed because one user asked me to make some fixes so that their DXF import would work as they expected.
OK, will do - right now I’m chasing a stunted thermal bug, which is rather more serious.
[quote=“cbernardo, post:5, topic:3540, full:true”] At the moment so few people seem to use DXF (or very few bother to comment) that many items which I consider bugs remained unreported and were only fixed because one user asked me to make some fixes so that their DXF import would work as they expected.
[/quote]
I think users are generally tolerant of only average DXF, but a search here finds 50 hits, so it is a feature that is used quite a bit.
If I had to rank things in order of simplicity/usefulness I would go something like
the above should need minimal DXF coding.
Next we have Fill polylines, which would need polyline preserve, but could use some layer rules.
ie maybe F.Keepout, B.Keepout, F.Fill, B.Fill need to become valid DXF layers.
A dummy net name could be in the form, for Fill entities.
I think most 2D CAD pgms support Named Blocks, so there could be a tick for
[] Use BlockName as Fill.NetName
and that gives pretty comprehensive DXF support, without going overboard.
I did some more tests on polylines, and what KiCad can tolerate.
There is a NET number, that could be a pain if enforced as external DXF has no knowledge of that.
Turns out, the net name is used, and the number is ignored/updated.
There are also optional fields around clearances & Spokes, so the minimal information is all available in a DXF reading, with little effort. (ie block name -> Net name )
A not-present dummy net name like DXF1 will import with warnings, and you can remap later.
Import of this
(zone (net 0) (net_name GND7) (layer F.Cu)
(fill yes )
(polygon
(pts
(xy -16.5 -50.5) (xy 102.5 -50.500006) (xy 109 -44.000006) (xy 109.000004 37.499994) (xy 100.250005 46.249995)
(xy -16.499995 46.25)
)
)
)
saves as this, after import.
(zone (net 3) (net_name GND7) (layer F.Cu) (tstamp 0) (hatch none 0.508)
(connect_pads (clearance 0.345))
(min_thickness 0.254)
(fill yes (arc_segments 16) (thermal_gap 0.508) (thermal_bridge_width 0.508))
(polygon
(pts
(xy -16.5 -50.5) (xy 102.5 -50.500006) (xy 109 -44.000006) (xy 109.000004 37.499994) (xy 100.250005 46.249995)
(xy -16.499995 46.25)
)
)
)