I think an important mechanic to implement in a persistent world where players can change things is to have things be resistant to change. Otherwise, you can have the clan like goon swarm that will murder entire cities "for fun." Instead, your world responds to this by the local lord or king to mobilize a squad, or even army, after the perpetrators. If you don't do things like this then players will feel free to do as they please regardless of consequences. Consequences can be fun. It's just a balancing act.

Tread lightly.
Multithreading an application only makes sense if work can be done independently. Even if you chain everything to just a single lock, you're still basically seeing single threaded performance. For example, a self contained routine to translate an email to a language can be split to multiple threads to convert a bundle of documents quickly. But, a routine that has a dependency that contains a lock will only see single threaded performance.
So, you need to fundamentally split your engine/framework/etc (whatever you want to make use of multiple threads) into partitions of work that can be done independently. It should be done in such a way that after you give your initialization parameters it's basically a self contained thing. This could be devoting a thread to UI. There are also techniques to break down physics simulations to handle discrete portions of a scene. These can be ran in parallel.
That's not to call locks bad. They have their use. But, if you're relying on locks alone then you're setting yourself up for failure. Given this, to try to Multithread Everything (TM) is a bad approach because not everything makes sense to be multithreaded. Also, when you get into multithreaded applications fixing bugs can be very tricky since you have zero control over precisely when something is executed. Be aware you're probably going to run into some seriously funky situations. Just be patient with those.

You're trying to convert the property to a type its graph doesn't support so it bombs. This is done by first assigning an object of the type you want to extract to the property before you do your foreach.
Edit: Saw this was on compile. This is strange. With casting as long as your "box" gets bigger, and not smaller, it's fine. Do you have VS set to fail on warn?

Thanks for your responses.
EarthBanana, no offense taken. I'm not experienced with game programming, per se, but have been a programmer for about seven years and more an engineer for about three. I understand concepts, though, so I tried to ask with that approach in mind. You've given me something to think about, though, so thanks!
Pink Horror, yes, this would be for an RPG. They're so damned attractive. Even if I fail, the mere pursuit would be worth it, to me. However, instead of trying to be an exact simulationist or traditionalist, I want to bridge the two concepts by making a lot of predetermined choices that the game can use to supplement otherwise inhibitively intense calculations. An example from my reading would be providing material friction coefficients up front rather than trying to calculate that at run time. That's not an intense equation, sure. It is just an example. But, the fundamental approach would be build tiny blocks that work with each other. The result, then, would be a system taking inputs and responding "naturally," insofar as the built-in assumptions are concerned.
I was hoping that by sticking to solid models rather than voxels I could cheat and calculate certain things as I need to rather than trying to keep all the voxels in memory at all times. But, the more I read, the better they seem to be in certain situations.

I have a thought on which I would value the community's feedback.
Say you have a tree. For ease of reference, this is just a cylinder. Now, you have an actor swinging an axe. Given a few variables, we know how deeply the axe can "cut" into the tree, the angle of the strikes and so on. Based on these angles and deepness of the cuts, I want to deform the base model potentially separating it entirely, doing some dynamic texture swapping to keep up the illusion you're actually chopping into a tree.
Does anyone see a computational hindrance here even when considering potentially hundreds of NPCs? Would it be possible to "destroy" the original model and have two models if you, say, chopped a wedge out of the side of this tree so they could then be interacted with independently?
No, I have not done any programming work on this myself, yet. I don't want to waste time on something that could prove to be a fool's errand. I'm just asking from a conceptual, theoretical basis. This is the tip of an iceberg should this be doable. I just thought this would be an "easy" starting point. I know there have been some examples with water and pouring between containers and with other liquids. My understanding of them is they work with, more or less, particle systems. This would be with solid models. I've thought about doing this with voxels, and while possible, I would prefer to use traditional models. I would think the tradeoff here would be putting more work on the CPU and GPU if what I'm asking about is doable versus keeping a voxel model and all that contains stored in memory at once.
Thanks!