So this would basically be a "break all existing code" .ini switch? I don't think 
that is a good idea.

Are there not other directives that can break a lot of code? Remember, this 
would default to off. I don't see why as a server owner, I should have this 
option made unavailable purely because it can break other code. If you wanted to 
write code that worked regardless of this setting, you could do something like:

<?php
init_set('implicit_open_tag', false)
?>

Of course, for that to work then implicit_open_tag is On, the parser would have 
to ignore the "<?php". The rule could be that if <?php is the first non-
whitespace sequence encountered in the file, then it's ignored. 
'optional_open_tag' may therefore be a more appropriate name for this setting. 
Except for legacy templates which may start with something other than <?php, 
this would allow for cross-environment code. Any such template code that breaks, 
would break in a manner no different to how new features like namespaces break 
in older version of PHP.

A new tag could be introduced: "<?php>". This would be shorthand for opening and 
closing a php tag, and should be placed at the top of any template file that has 
the requirement to work regardless of whether the opening tag is optional.

I hope this idea isn't dismissed on the grounds that it's difficult to 
implement, because I think it's workable. Having optional opening tags would no 
doubt be a step in the right direction for PHP, and I'm sure that if you didn't 
have backwards compatible to be concerned about, you'd probably make opening 
tags implicit with no option to make it otherwise. As I said earlier, the 
decision to make the opening tag explicit was desirable at the time PHP was conceived, but I believe it's one of those legacy decisions that needs to be re-
evaluated.

So, basically, you're suggesting that programmers should write "<?php>" at the begining of the file to not write "<?php". Blarg.

Of course this "<?php>" thing is optional. The problem is that virtually any code has to use it to be portable. This means it's not really optional.

Sorry, I have misunderstood the "<?php>" tag. Thought it's used to *enable* `assume_open_tag`. But, if you want to use it to disable the feature, it's even worse. This breaks lots of existing code. Mixing PHP with HTML is an example of bad design, but there are lots of such things and PHP devs can't just say "from today your code is not working, because we have decided to break it". Adding some magical sequence of characters at the begining is not a solution for this problem. Do you imagine administrators going through all of the files on their servers and adding "<?php>" to fix the broken code? Even harder to imagine in case of obfuscated or PHARed code.

I believe there is enough problems with server incompatibilities already. No need to make next one. I would be much more happy to see UTF-8 to be a standard feature on every host. A requirement to write "<?php" doesn't bother me. Copyright notices and namespace declarations/imports use much more space.

After a bit of thinking I came to a conclusion that PHARs can, in theory, have such thing implemented. Some metadata may be included in PHAR to tell PHP that every source file in the archive assumes "<?php" tag to be open. Since such information is included by the author of the code, nothing can be broken.

However I don't know if it's worth being implemented. As I said before, it gives almost nothing. Five characters is not much if one have to put dozen lines at the begining of each file. Also PHARs, that assume opening tag to be open, should be incompatible with older versions of PHP to prevent sending source code to the client by accident. Too much trouble IMO.

It's not just about the extra characters, but like the end ?> tag (which 
thankfully is optional), any white-space or otherwise non-printable characters 
before the opening tag can cause "headers sent" issues. You could solve that 
problem by implementing the ignore white-space rule I've already mentioned, 
where any white-space before the opening tag is ignored.

The more I think about this and talk to the others, the more it becomes apparent 
that what I'm actually asking for, is a distinction to made between PHP 
templates, and PHP scripts/applications. If PHP were to define these two 
distinct concepts, then you could do more than just make the opening tag 
optional. For example, you could have a template() or render() method to act as 
an include() for php templates. Unlike include() however, this render() method 
would return the output of the file, instead of sending it straight to the 
browser. This would negate the need to capture template output using the output 
buffer functions (something that I believe most frameworks end up using).

Making such a distinction would also allow web servers like Apache to treat PHP 
files differently. You may create a rule in Apache to render all .phpt files as 
PHP templates, rendering everything else as PHP script or application files. We 
may then see mod_php implement an application mode, where one can define a 
single-point of entry into their application. This could have flow-on 
performance benefits, where mod_php could cache the parsed PHP, then either fork 
it on each request, or instantiate a new application class. Such a feature would 
mean frameworks wouldn't have to stuff around with .htaccess files, and would 
mean that programmers don't need to add the following to the top of all their 
files: if (defined('SOME_CONSTANT')) exit;

While there's momentum among the PHP developers to move forward with modernising 
the language, I think now would be a good idea to consider some of these more 
fundamental changes. PHP's built-in template engine, ease of deployment, and 
it's dynamic, traditional OO constructs would still remain PHP's strengths.

With all this said, I'd be happy to save such changes to a major release 
intended to break legacy code, like PHP 6. I'd like to keep in mind too that 
code portability isn't relevant to most people who don't intend to release their 
code as open source. Typically, those people using PHP in a business context 
have control of their server. It's only shared hosting environments where 
portability becomes a potential issue. All I'm saying is don't rule out ideas 
based on the lowest common denominator.

Note: I'm NOT against the idea itself. I'm just thinking that in the current form it can do more harm than good.

What you're asking for is redefining the whole PHP world. Let's imagine that PHP6 includes your idea and it's *not* optional. What happens?
1. Many of PHP books become obsolete
   We all know mixing code and output is bad, but the books
   take this approach because it's simpler. It allows authors
   to show the basic ideas of PHP without requiring the reader
   to download/install third party template engine.
   But if .php files are no longer templates, books need
   to be rewritten. Lots of money for authors, but I think
   it's not dev's goal.
2. Lots of currently used code becomes obsolete
   If one needs to write code for a server that has
   this feature enabled, any template-like code should
   be avoided. This means we can use only "safe" libraries.
   Which are "safe"? Only those for which the author states
   they're compatible with `assume_open_tags`.
   In other words: less code for us to use. Many things needs
   to be rewritten. This is bad.
3. Admins will simply refuse to enable the feature
   I love the idea of removing magic_quotes. At the same time
   I believe many admins will hesitate to upgrade to PHP6,
   because they have irrational belief that the magic_quotes
   feature was protecting them.
   Now imagine what will they do with `assume_open_tags`.
   Will they enable it? Will they risk breaking already
   deployed applications? I don't think so. If they're afraid
   to leave their servers without magic_quote "protection",
   they'll be even more scared of the fact that they can beak
   something seriously by enabling `assume_open_tags`.
   Setting `assume_open_tags` on per-directory basis (for example
   with .htaccess in Apache) doesn't solve the problem, because
   PHP libraries may be shared between multiple applications.
I believe that books should be rewritten, real template engines should be used, we should update our code et cetera. But real life is real life. Encountering pieces of software that were not upgraded for 20-30 years is not an uncommon thing ("20-30yrs" does not apply to PHP, but I know apps that were not updated since PHP4). `magic_quotes` are deprecated for years and many people seen they're bad even earlier. There was enough time to update applications that depends on them. And even if some code is not fixed, removing magic_quotes doesn't make it stop working. The case of `assume_open_tags` is different. If it's optional, it needs to become a standard to be accepted. And this should be done quickly. I can't imagine building separate versions of libraries for server with this feature enabled and without it. Authors will simply keep using versions with "<?php" to maintain compatibility and the proposed feature will stay unused.
OTOH forcing it to be enabled will cause problems mentioned above. This is a lose-lose situation.

IMHO this may work only if the author of the code decides which mode to use. This makes the feature really optional. It may be included in the server without breaking any existing code and be enabled if new code requies it. This way the feature may be introduced gradually. Evolution, not revolution.
The question is: how to enable authors to tell that their code assumes that opening tags are open?
The first idea was to add some metainfo to a PHAR.
The second, based on your last post, is to add an optional argument to include*/require* constructs. In such case the following code would cause included file to be parsed as a raw PHP source, not requiring additional "<?php".
  require_once some_magic 'ns1/ns2/Example.class.php'
There still needs to be a file with "<?php" at the begining to use this code. However currently the trend is to use a single dispatcher, so it's not a big deal.

Still I'm not sure if the feature is really worth being implemented.

I do agree with you, hence my last comment. Adding optional open tags alone 
would be more hassle than it's worth, you're right. However, if PHP was to 
provide more than just optional open tags, like some of the application-
orientated features I've mentioned, then the hassle would probably be worth it. 
Of course, this goes beyond the scope of this feature request, but it would make 
for an interesting discussion none-the-less. PHP is overdue to receive some kind 
of application persistance so code isn't re-parsed and re-initialized after 
every request.

I'm happy for this ticket to be closed, though I would love to see more thought 
put into evolving PHP beyond its current template-orientated form, which lately 
seems to work against developers more than it helps them.

There are still people who mix PHP and HTML code and that is still valid. Yes, this change would save typing 6 characters (<?php + new line) per file but cause lot's of compatibility and related issues which isn't really worth it.

I have to agree with the sentiment.

Standard convention seems to be to exclude the close tag on PHP-only files, but 
I find it fundamentally flawed and improper syntax to have an unclosed tag. I 
just can't look at a PHP file with it excluded and see it as "clean".

That said, I'd support an initiative to change the nature of the open tag--
either through its removal or changing it to something else identifiable as a 
PHP "starter" that's clearly not an opening tag.

I also find it completely viable for this to be a server-level option, or 
something that can be toggled through Apache on a per-vhost basis.

There's a few logical paths I can think of:

1. If the file's extension is .php then ASSUME it's pure PHP, but if there's a "
<?php" tag anywhere in it, fall back to the current assumption of it being a 
mixed file. This should help ensure backwards compatibility and might not even 
need to be a configuration change.

2. This one being a configuration change, assume all .php files are pure PHP, 
assume all .phtml files are mixtures.

3. Support "<?php?>" (or something else) as a first-line identifier of a pure 
PHP file

There are plenty of ways to evolve "<?php" for pure PHP files. Some that can 
work in parallel to today's conventions, some that are more abrasive.

In the meantime, I just don't want to be condemned for closing my tags, which 
has been a discipline encouraged (if not enforced) for many years. Frankly it 
absolutely amazes me that so many people are suddenly alright going against that 
simple principle. So much for consistency...