Sharing data between graphics and physics engine in the game?

I'm writing a game engine that consists of a few modules. Two of them are the graphics engine and the physics engine.

I wonder if it's a good solution to share data between them?

Two ways (sharing or not) looks like that:

Without sharing data

GraphicsModel{
    //some common for graphics and physics data like position

    //some only graphic data 
    //like textures and detailed model's vertices that physics doesn't need
};

PhysicsModel{
    //some common for graphics and physics data like position

    //some only physics data 
    //usually my physics data contains A LOT more information than graphics data
}

engine3D->createModel3D(...);
physicsEngine->createModel3D(...);

//connect graphics and physics data 
//e.g. update graphics model's position when physics model's position will change

I see two main problems:

1. A lot of redundant data (like two positions for both physics and graphics data)
2. Problem with updating data (I have to manually update graphics data when physics data changes)

With sharing data

Model{
     //some common for graphics and physics data like position
};

GraphicModel : public Model{
    //some only graphics data 
    //like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel : public Model{
     //some only physics data 
    //usually my physics data contains A LOT more informations than graphics data
}

model = engine3D->createModel3D(...);
physicsEngine->assignModel3D(&model); //will cast to 
//PhysicsModel for it's purposes??

//when physics changes anything (like position) in model 
//(which it treats like PhysicsModel), the position for graphics data 
//will change as well (because it's the same model)

Problems here:

1. physicsEngine cannot create new objects, just "assign" existing ones from engine3D (somehow it looks more anti-independent for me)
2. Casting data in assignModel3D function
3. physicsEngine and graphicsEngine must be careful - they cannot delete data when they don't need them (because the second one may need it). But it's a rare situation. Moreover, they can just delete the pointer, not the object. Or we can assume that graphicsEngine will delete objects, physicsEngine just pointers to them.

Which way is better?

Which will produce more problems in the future?

I like the second solution more, but I wonder why most graphics and physics engines prefer the first one (maybe because they normally make only graphics or only physics engine and somebody else connect them in the game?).

Do they have any more hidden pros & cons?

Nowadays, more game engines adopts a component design (e.g. Unity, Unreal). In this kind of design, a GameObject is composed of a list of components. In your situation, there can be a MeshComponent and a PhysicalComponent, both attaching to a single game object.

For simplicity, you can put a world transform variable to the GameObject. During update phrase, PhysicalComponent outputs the world transform to that variable. During rendering, the MeshComponent reads that variable.

The rationale behind this design is to decouple between components. Neither MeshComponent nor PhysicalComponent knows each other. They just depends on a common interface. And it can be easier to extend the system by composition, than using single hierarchy of inheritance.

In a realistic scenario, however, you may need more sophisticated handling between physics/graphics synchronization. For example, the physics simulation may need to be run in fixed time step (e.g. 30Hz), while rendering need to be variable. And you may need to interpolate results from the output of physics engine. Some physics engine (e.g. Bullet) has direct support of this issue though.

Unity provided a good reference of their Components, which worth a look.