This is pretty basic but since I have not seen it clearly documented, except on this thread on the Live Framework forum, I thought it worth documenting. There is a subtle difference in the propagation behavior of mesh objects created locally and those created on the cloud.
Mesh objects created on the cloud are propagated automatically to the local device and mesh objects created locally are propagated automatically to the cloud. However, this symmetric behavior does not extend to the data feeds and the data entries contained in them. A data feed created locally is propagated automatically to the cloud but a data feed created on the cloud is not propagated automatically to the local environment.
A mesh object created on the cloud must be mapped to the local device to make its data feeds available locally. This applies trivially to any data entries attached to the data feed because if the data feed is not available the data entries associated with it are also not available locally. A mesh object created locally does not need to be mapped to make its data feeds available on the cloud. Mapping is achieved by creating a mapping resource and then associating it with the local device and the mesh object as follows:
MeshDevice meshDevice = (from md in mesh.CreateQuery<MeshDevice>()
where md.Resource.Type == "Computer" & md.Resource.Title == "LOCAL_DEVICE_NAME"
Mapping mapping = new Mapping("MAPPING_NAME");
mapping.Device = meshDevice;
This will add a mapping entry for the local device to the Mappings collection for the mesh object. There will now be full symmetry in the behavior of data propagation between the cloud and the local device. Curiously, both the cloud-created and locally-created mesh object will have a mapping entry for the cloud but only the locally-created mesh object will have a mapping entry for the local device.
UPDATE 3/7/2009: Ben Williams of Microsoft has put out a long post Moving From Local LOE to Local LOE which tells you everything you need to know about device mappings.