Fundamentally flawed design limitation in configuration?

[kiwidude68]

I can appreciate the library hasn't been touched for many years, the author has clearly moved on which is a shame as there are some interesting ideas in here. But just in case anyone else like me stumbles upon this and thinks about using it - my advice is don't, unless you have the most trivial of use cases.

The bug/problem is if you have a nested child property that is an object, not a simple property or an IEnumerable. In that scenario, the code does not (currently) do an engine.Get to lookup any configuration for it, and instead just re-uses the parent object configuration. This prevents you from then ignoring child properties of that child object. This is indirectly pointed to in this issue, where the reporter points to read-only properties - the problem is child object properties, not specifically read-only ones.
#26

I've looked through the code and the tests, it is pretty simple to come up with a test that breaks it. In the EngineTests the Compare_Nested_Objects() test is a candidate, try to setup an ignore of say ChildModel.Name or GrandChildModel.Value. You will find such an exclusion gets ignored.

UPDATE:
The code that needs to be changed s in Builder.GetSafeguardedRecursiveExpression() to have it lookup the configuration for the child type...