When retrieving profiles for custom objects in a project.xml manifest, the returned profiles do not contain the objectPermissions object for objects that they do not have access to (ie no CRUD permission).

Steps to reproduce:
Open a force.com developer edition instance
Create an object named Object__c.
Create a profile named Profile without any access to Object__c.
Retrieve from metadata API (v.28 / eclipse) using the following package.xml

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>Object__c</members>
<name>CustomObject</name>
</types>
<types>
<members>Profile</members>
<name>Profile</name>
</types>
<version>28.0</version>
</Package>

See that the profile received is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
<userLicense>Salesforce</userLicense>
</Profile>

Before the Winter 14 upgrade, the profile contained:
<?xml version="1.0" encoding="UTF-8"?>
<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
<objectPermissions>
<allowCreate>false</allowCreate>
<allowDelete>false</allowDelete>
<allowEdit>false</allowEdit>
<allowRead>false</allowRead>
<modifyAllRecords>false</modifyAllRecords>
<object>Object__c</object>
<viewAllRecords>false</viewAllRecords>
</objectPermissions>
<userLicense>Salesforce</userLicense>
</Profile>


Enable read access to the Object__c object for Profile.

Refresh from server, and see that the profile now contains:
<?xml version="1.0" encoding="UTF-8"?>
<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
<objectPermissions>
<allowCreate>false</allowCreate>
<allowDelete>false</allowDelete>
<allowEdit>false</allowEdit>
<allowRead>true</allowRead>
<modifyAllRecords>false</modifyAllRecords>
<object>Object__c</object>
<viewAllRecords>false</viewAllRecords>
</objectPermissions>
<userLicense>Salesforce</userLicense>
</Profile>

We can see that the objectPermissions tag for that object is not retrieved in this profile when the profile has no access to the object.

Has anyone else encountered this issue, and found a workaround? This is causing issues for us, because if we remove object access from a profile, it will not be available to commit to our source control, and will not be updated when we deploy metadata to another enviornment.