I am just another user of DBIx::Class, not a developer, so there is no point telling me that the design might be wrong.
In what situation do you anticipate a race condition? To me that implies two different processes with separate connections to the database, so it would be meaningless for them both to see the same object.
In the case of reducing the overhead of multiple database queries, in my experience it is not a problem. If you are using the same row object twice close together (in time or in code terms), then it is easy enough to keep it in scope. If the two uses of the object are a long time apart, or in distantly related parts of program then it would be better to do fresh database queries to avoid the risk of stale objects. Remember that the database will be caching the rows, so if it has not changed between accesses, then the cost of retrieving it a second time will be small. Why put code to check if it has changed in DBIC as well, when it is already in the back end database.
