Hopefully this suggestion isn't completely insane.  What if we update the schema to accommodate *all* the member related calls, that is, member-create, member-show, and member-update?  I think the following will work.  I tested it out quickly in the online json-validator, and it does seem to handle the current request bodies and request response.

http://jsonschemalint.com/draft4/#

Here's the schema:

{
    "id": "http://openstack.org/glance/member/schema#",
    "$schema": "http://json-schema.org/draft-04/schema#",
    "description": "OpenStack Glance image member schema for member-create, member-detail, and member-update requests.",
    "type": "object",
    "oneOf": [
        { "$ref": "#/definitions/image-member-create-request" },
        { "$ref": "#/definitions/image-member-detail-response" },
        { "$ref": "#/definitions/image-member-update-request" }
    ],
    "definitions": {
        "image-member-create-request": {
            "additionalProperties": false,
            "properties": {
                "member": {
                    "description": "An identifier for the image member (tenantId). (The image_id of the image to which this request applies is specified in the path of the request.)",
                    "maxLength": 255,
                    "type": "string"
                }
            },
            "required": [
                "member"
            ]
        },
        "image-member-detail-response": {
            "additionalProperties": false,
            "properties": {
                "created_at": {
                    "description": "Date and time of image member creation",
                    "readOnly": true,
                    "type": "string"
                },
                "image_id": {
                    "description": "An identifier for the image",
                    "pattern": "^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){12}$",
                    "readOnly": true,
                    "type": "string"
                },
                "member_id": {
                    "description": "An identifier for the image member (tenantId)",
                    "maxLength": 255,
                    "readOnly": true,
                    "type": "string"
                },
                "schema": {
                    "readOnly": true,
                    "type": "string"
                },
                "status": {
                    "description": "The status of this image member",
                    "enum": [
                        "pending",
                        "accepted",
                        "rejected"
                    ],
                    "readOnly": true,
                    "type": "string"
                },
                "updated_at": {
                    "description": "Date and time of last modification of image member",
                    "readOnly": true,
                    "type": "string"
                }
            },
            "required": [
                "created_at",
                "image_id",
                "member_id",
                "schema",
                "status",
                "updated_at"
            ]
        },
        "image-member-update-request": {
            "additionalProperties": false,
            "properties": {
                "status": {
                    "description": "Status to which the image member should be set. (The image_id and member_id are specified in the path of the request.)",
                    "enum": [
                        "pending",
                        "accepted",
                        "rejected"
                    ],
                    "type": "string"
                }
            },
            "required": [
                "status"
            ]
        }
    }
}

Pros:
1. present behavior of api is maintained
2. not much change in code (just the schema generation code, i think)
3. I don't think this will require any glanceclient changes

Cons:
1. schema is kind of complicated, but the oneOf structure makes it fairly human readable, and of course machines aren't going to care