That would make for an easier situation. If we don't worry about legacy for a moment that would give us this cleaner bitfield.
Bit 0 -- Standard tags toggle 1 -- Short tags toggle 2 -- ASP tags toggle 3 -- Script tags toggle 4 -- Short echo toggle. For backwards compat ship with bits 0 and 3 set on. The existing short tags mode is bits 1 and 4 on. If all the bits are turned off then we have the PHP_TAGS_NONE setting. In that mode the engine must assume the whole file is going to be PHP code since there are no tags to look for. I honestly like this best of what has been suggested so far, BUT the need to adjust settings after upgrade is a major concern. Admins who never enabled asp or short tags to begin with wouldn't notice the settings going away, and those that have I would expect to be savvy enough to transfer the setting change themselves. Another possbility is to have PHP set tag_style according to whether it sees short_open_tags and asp_tags in the ini file. If either of them are on, and tag_style wasn't explicitly set, then php will set tag style to the values it must have to mimic the intent of the setting. If tag_style is explicitly set then it wins out - but a deprecated notice gets thrown to alert the user that they have both tag_style set and short_open_tags and/or asp_tags set on. If an htaccess or httpd.conf directive explicitly calls for short_tags or asp_tags after tag_style was explicitly set a warning of some sort is thrown informing the user that they must switch that declaration to one compatible with the php.ini file. Ditto for sets occurring at runtime with one exception - if the user specifies tag style from the include or require statement itself this shouldn't raise any error. (That there's no comment on the adding of the second param to those function as of yet concerns me a little - it is somewhat key to the proposal.) Anyway, the trickiest part of this is balancing the past with the future.
