FO4 VMADs with complex script properties still parse incompletely

[EyeDeck]

What is the version of xEdit you are using?
FO4Edit 4.1.2p EXTREMELY EXPERIMENTAL (3854AB12)
FO4Edit 4.0.3 (1CDF3AC7)
FO4Edit 3.3.10 BETA (C9BB14F9)
FO4Edit 3.2.72 EXPERIMENTAL (42567E08)
All displayed identical behavior.

Describe the bug
Test mod for demonstration

Script properties with complex structures, i.e. where structs are within structs, and especially arrays (potentially of structs) within structs, still often do not parse correctly. Presumably as a result of this, manipulation of records that do not parse correctly may corrupt the record.

Using the data structure from hell I made for the test mod:

As parsed by xEdit

property testStructA =
[
	level = 1,
	recursion =
	[
		level = 2,
		recursion =
		[
			level = 3,
			recursion =
			[
				level = 4,
				recursion =
				[
					level = 5,
					moreRecursion = 
					[
					* Note that this part appears to parse correctly,
				but if manipulated, resaved, and then opened in the CK,
				the value of moreRecursion here shows up as <<Unknown>>
						[
							level = 6
						]
					],
					recursion = 
					[
						level = 6,
						recursion =
						[
							level = 7
						]
					]
				]
			]
		]
	]
]

To reproduce
Steps to reproduce the behavior:

1. Load SillyScript.esp
2. Compare parsed properties in __TestQuest in xEdit to CK property dialog

An example of weirdness when manipulating one of these records:

1. Load SillyScript.esp
2. Copy as override into... -> any other plugin
3. Notice how the override differs from the original record

Expected behavior

Parsed by the game, this is how the data structure looks

This is as printed by the game to the Papyrus log, then prettified by hand.
Note that game fills in data about the script that xEdit wouldn't know (unassigned values).

property testStructA =
[
	level = 1,
	recursion =
	[
		level = 2,
		recursion =
		[
			level = 3,
			recursion =
			[
				level = 4,
				recursion =
				[
					level = 5,
					recursion =
					[
						level = 6,
						recursion =
						[
							level = 7,
							recursion = None,
							moreRecursion = []
						],
						moreRecursion = []
					],
					moreRecursion =
					[
						[
							level = 6,
							recursion = None,
							moreRecursion = []
						]
					]
				],
				moreRecursion = []
			],
			moreRecursion = []
		],
		moreRecursion = []
	],
	moreRecursion = [
		[
			level = 2,
			recursion = None,
			moreRecursion = []
		],
		[
			level = 2,
			recursion = None,
			moreRecursion = []
		],
		[
			level = 2,
			recursion =
			[
				level = 3,
				recursion = None,
				moreRecursion = []
			],
			moreRecursion = []
		]
	]
]

How xEdit should parse it, probably

Same as above, but with the unassigned values that xEdit couldn't know about removed.

property testStructA =
[
	level = 1,
	recursion =
	[
		level = 2,
		recursion =
		[
			level = 3,
			recursion =
			[
				level = 4,
				recursion =
				[
					level = 5,
					recursion =
					[
						level = 6,
						recursion =
						[
							level = 7
						]
					],
					moreRecursion =
					[
						[
							level = 6
						]
					]
				]
			]
		]
	],
	moreRecursion = [
		[
			level = 2
		],
		[
			level = 2
		],
		[
			level = 2,
			recursion =
			[
				level = 3
			]
		]
	]
]

Additional context
I thought #544 fully addressed this, but I never looked closely enough at it to notice the remaining bugs.

[ForsakenShell]

Can confirm this issue is still present. I have a struct array where the struct contains struct arrays. Funny thing is, xEdit was working fine with this until it suddenly wasn't. This has put a mod I've spent several months on to be on permanent hiatus until this can be resolved as my xEdit script cannot parse my "production version record" to create the "release version record" with the proper script property values.

[ElminsterAU]

should be resolved with the commit referenced above (to be included in 4.1.3j, not in 4.0.x)