I am revising this issue again as I realized that this is not as I thought LWPOLYLINE bug, but normal bahaviour of this entity type... So, I figured out that this issue occur when starting vertex of LWPOLY is positioned such that offseting calculation is not possible... For instance you have rectangle and one smaller rectangle crossing bigger side of bigger rectangle, then when you trim lines to get boundary outline and perform JOIN command, usually starting vertex is common intersection of those 2 rectangles. Now if you try offset you'll see that previewing is possible all until smaller boundary rectangle shape is present. When you move mouse beyond that distance instead of previewing now only bigger boudary rectangle offset shape, small icon (-) will pop up telling that this isn't possible... So I instead of exploding and rejoining lines to new LWPOLY, decided to change initial vertex of LWPOLY... And whoala, that did the trick... It is possible that when explode and rejoining, newely created LWPOLY changed initial vertex automatically - this happens also if you perform one single REVERSE command... But this all is not very reliable - I figured out that you should check every position of starting vertex so that you could be sure if offset is possible or not... This finding tells me that routines may be more slower, but this checking is necessity if you want to be sure that this situation not happen (offset bug)...
So here is routine for checking and you may strip sub function from it :
(defun c:CHIV ( / osm ss e f ed edd eddd eddd1 eddd2 eddd3 newed p m n i )
(vl-load-com)
(setq osm (getvar 'osmode))
(setvar 'osmode 1)
(prompt "\nPick closed 2d polyline with or without arcs")
(setq ss (ssget "_+.:E:S:L" '((0 . "*POLYLINE") (-4 . "<or") (70 . 1) (70 . 129) (-4 . "or>"))))
(if ss
(setq e (ssname ss 0))
(progn
(setvar 'osmode osm)
(alert "Picked wrong entity... Please pick normal closed 2d polyline next time-quitting...")
(exit)
)
)
(if (eq (cdr (assoc 0 (entget e))) "POLYLINE")
(progn
(setq f t)
(vl-cmdf "_.convertpoly" "_l" e "")
)
)
(setq ed (entget e))
(setq edd nil)
(foreach ec ed
(if (not
(or (eq (car ec) 10) (eq (car ec) 40) (eq (car ec) 41) (eq (car ec) 42) (eq (car ec) 91) (eq (car ec) 210))
)
(setq edd (cons ec edd))
)
)
(setq edd (reverse edd))
(setq eddd nil)
(setq eddd1 nil)
(setq eddd2 nil)
(setq eddd (member (assoc 10 ed) ed))
(setq p (getpoint "\nPick vertex you want to become initial"))
(setq m (vlax-curve-getparamatpoint e (vlax-curve-getclosestpointto e p)))
(if (assoc 91 ed) (setq n (* m 5)) (setq n (* m 4)))
(setq i 0)
(foreach ec eddd
(progn
(setq i (+ i 1))
(if (<= i n)
(setq eddd1 (cons ec eddd1))
)
(if (> i n)
(setq eddd2 (cons ec eddd2))
)
)
)
(setq eddd1 (reverse eddd1))
(setq eddd3 (list (assoc 210 eddd2)))
(setq eddd2 (cdr eddd2))
(setq eddd2 (reverse eddd2))
(setq newed (append edd eddd2 eddd1 eddd3))
(entmod newed)
(entupd e)
(setvar 'osmode osm)
(if f
(vl-cmdf "_.convertpoly" "_h" e "")
)
(alert "After CHIV, run PEDIT->Edit Vertex to see change")
(princ)
)
So after all, there is no need for destroying LWPOLY and XDATA issue can be saved by applying this method of checking starting initial vertex along LWPOLY by simply iterating through all positions that are stored in LWPOLY entity data...
HTH., M.R.