I address most of your design concerns in my new "Domain Driver" framework on CodePlex (http://domaindriver.codeplex.com). Particularly, I provide a TransactionScript class to fix your first problem and I show and example of "copy-in-place" ofr child objects to preserve changes and ease database updates.
Overall, Domain Driver provides developers with a way to quickly and easily implement a full domain model, to test that domain model using pre-built generic tests, and to prototype user-inferface components against that domain model to help achieve customer validation. Initially, the domain model will function as an in-memory database, but at any point developers can add the ability to persist to a database, a file, or any other non-volatile data store.
Domain Driver itself is decoupled from any persistence technology, but I implemented an example that clearly shows how to use it with EF Code-First to accomplish Database persistence.