Since the protection settings on Wikipedia are only visible with the proper rights, here a screenshot of the current interface to provide context:

Some thoughts from the technical side:

Page protection is stored in the page_restriction table:

CREATE TABLE `page_restrictions` (
  `pr_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `pr_page` int(11) NOT NULL,
  `pr_type` varbinary(60) NOT NULL,
  `pr_level` varbinary(60) NOT NULL,
  `pr_cascade` tinyint(4) NOT NULL,
  `pr_user` int(11) DEFAULT NULL,
  `pr_expiry` varbinary(14) DEFAULT NULL,
  PRIMARY KEY (`pr_id`),
  UNIQUE KEY `pr_pagetype` (`pr_page`,`pr_type`),
  KEY `pr_typelevel` (`pr_type`,`pr_level`),
  KEY `pr_level` (`pr_level`),
  KEY `pr_cascade` (`pr_cascade`)
)

This means there can be one protection record (row in the page_restriction table) per page per type, so it's already possible to record full protection and semi-protection separately. This means that this wish can probably be implemented without a schema change.

Without having read the relevant code, it seems the different protection types can be managed separately as follows:

• when checking the protection of a page, collect all (non-expired) protection records. Apply permission checks as appropriate for each protection type. The permission check must succeeded for each type.
• when updating the protection of a page, only the selected protection type should be overwritten in the table, protection records with other types should stay untouched.
• the UI for changing page protection should show all current protection records along with their expiry

I'd like to see an optional set of parameters for protection to solve this. 2 possible workflows:

1. Allow applying multiple protection types with related expiration - and AND them when checking if someone has edit permission.
2. Add a "When expires DO" workflow so you can specify what to do when a single protection expires (default being do nothing).

(1) is the most flexible, but (2) has a unique feature that you could set a page to be temporarily LOWER protection, then have it automatically become higher at a later time.