User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101
            Thunderbird/31.5.0
MIME-Version: 1.0
References: <1o9mof44i4wtd$.dlg@nililand.de> <54F3B375.8090006@nag.co.uk>
            <1059aehsadqtw$.dlg@nililand.de>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2015 13:30:18.6644 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR05MB354
Message-ID:  <54F465E7.9050709@nag.co.uk>
Date:         Mon, 2 Mar 2015 13:30:15 +0000
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: David Carlisle <davidc@NAG.CO.UK>
Subject: Re: LaTeX2e Update 2015 problem
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <1059aehsadqtw$.dlg@nililand.de>
Precedence: list
List-Help: <http://listserv.uni-heidelberg.de/cgi-bin/wa?LIST=LATEX-L>,
           <mailto:LISTSERV@LISTSERV.UNI-HEIDELBERG.DE?body=INFO%20LATEX-L>
List-Unsubscribe: <mailto:LATEX-L-unsubscribe-request@LISTSERV.UNI-HEIDELBERG.DE>
List-Subscribe: <mailto:LATEX-L-subscribe-request@LISTSERV.UNI-HEIDELBERG.DE>
List-Owner: <mailto:LATEX-L-request@LISTSERV.UNI-HEIDELBERG.DE>
List-Archive: <http://listserv.uni-heidelberg.de/cgi-bin/wa?LIST=LATEX-L>
Envelope-To: <rainer.schoepf@GMX.NET>
X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3;
X-GMX-Antivirus: 0 (no virus found)
X-UI-Filterresults: notjunk:1;V01:K0:B9zTYK7X9rQ=:hf7KJTgVWKcnN7nuv3Ncy+dwX+
 lzMaoKvt8PstFpaTYFpkhp30Xzgz7EDAxnRWzFjoO32e1iL5I7GPkaE7s6LSyvKepGcmsTofu
 YTQ1PJFJK4+1S0KEc1dmYmHvTyUBTLPWw7zO47crthBUwwwyliACviY6OUDSBhnIR2JEgG5Ha
 Xe3q3+3KunVZGpy28XwjW5R8FwbgQ2qb4kp45MI1yV86yrXeUXJTWE8TwIsxCgUP66/DXhfhg
 /Vvk3zHWGSfAZkdyZR8QWvA/oUZXfhaIqJlz3a1CixF7JvtfYHji8KEgfhutBVqB9Lml/zlP2
 GT7Xp2paOcbfSRa4gaHDfYm8y5O3atz4YQSdlojVqIyZHpTea31jQXgHAQwi2wLk03jcbjzaY
 awit6g/3LbyE7bltVUmFrJtpZtT8YzE2hcJrUCm2VnTLPAbzaa/6GK6QMVv9luxMUHqUJl4zh
 P+/WC1fP51Nark286DL46WOJwCv9q9sIjPQWWJ6phoaI0dFDIQopKXwI+vPhHY5CGw+EGZr3c
 MP4ytHVV71VVKTJL3Qn9fv1O8XkcPIW+TxMYrGVdJ6VhVKKSW+wCuSc1tsT/yB3tuo+iWfkM2
 qK0Tv118lAsktfl07AN0w43AuMk38yoJhN/MkbKl1TBVrvrDRIuOifC3dhT4MYAg76gTaPZwZ
 thkQX39c+pq8yU+0gniiul/ewsweAjeuxc2p+B/T/j390MGLwc5hiXYfx4R+e05qmed49OzYR
 rSbP4qXH7ryAIZBiDxiME8023S/wf8dRdLFZXncH9Yp87u8W3WPHP+dITBTRlcBiGqsgu/tPA
 8aXr0JKhcVmUxsNFh4TLKjQMHKHbOSC5ir0uP2LDAhY4WZM6vgnuSINjCWr5u5LVgUflmkc1i
 wtfz2UrHkBzF8KipgU0445dD+tiPKOsFO6yUt8O5sU/K8aElZ8ZHztopXoFV7BnyY/uOVHkyL
 PI9WKY/IwRFtvzJJQUiY5Bk+sKXWIM4wDO79iBqaNpZKFcxAYrbcHKR6gW6BgeEEsqMJKDnoS
 rkXCyfZGzULPmOx0LLM8rwtcL7M9kG6GdTW0ZucZb8MqZBB99l8fOZ952af8I9VO5w/h/S9Ry
 GUxqhROLnAmI/MwG0afe77MHcjFeo6Wbz0et59dBpRYtjy86BxIzhmWlcgU+7rDvOdu0tAu8H
 WAfS3ZfGP6yiG/3el2Q37vHjoL/XyjAKOrXLwuofXqIRQZCG8vONVwqzIGuHfL5FB3ftfUpnt
 1DB0erSpi8nI5Twj8fUV4eC/C6iZKbWu68CpBeHfmLkLczHg6Q/3DB/EcffR1ubisb+FYWv4e
 0q7+hmQ49vanecyrewkitN1AGkXYGPfBUX4dskI+M7nw5VXMQd3y0k5sYQfNO1IzY8+iYttfK
 o+9NidPXGDKz781YzeqPvGvBnxlSmC++MdnMrOKAZ/8wJ/ZXw2kVNNE4JrRW75o2yQunJmiDF
 QbEUK0jeeADHVWSjScBoKqeXUA6kk1AiAyCNFwwoQsBOq4j2y0
X-UI-Loop:V01:IVvucVg1jqU=:fU/1Pu7dGo8WZBreAIjE4OKvYyWcsvUtlroQL6ARri0=
X-UI-Out-Filterresults: notjunk:1;
X-Scanned-By: MIMEDefang 2.71 on 85.214.41.38
Status: R
X-Status: 
X-Keywords:                  
X-UID: 7669

On 02/03/2015 08:36, Ulrike Fischer wrote:
> This doesn't work. Regardless where I put the \RequirePackage{etex},
> I get the same error.

That's odd, it worked for me. (I'll see if I can reproduce)
But in any case that isn't a viable fix it was just intended to be an
indicator of where the problem lies.

> The only thing that works is suppressing etex altogether with
>
> \expandafter\def\csnamever@etex.sty\endcsname{}
>
>
>>> Alternatively etex.sty could be adjusted to recognise the new
>>> format (for example an etex.sty that did nothing at all would
>>> work in this case)
> That would certainly a good idea.

Yes, probably something like this. Doing nothing at all works in this
case and in fact in the vast majority of cases that I can see in a
texlive 2014 tree, as etex.sty is just loaded so that \newcount doesn't
run out of registers at 255. However there are some packages that may
load etex and then expect the exact same implementation or a definition
of `\loccountblk` or something. It's hard to find any uses of
`\loccountblk` outside test files, but the internet is a big place...

So the original idea was to allow etex.sty to over-write the allocation
system to give exactly the old etex.sty behaviour. As far as I can see
that should work so long as etex.sty is loaded before extended registers
are allocated but I'll see if I can reproduce your failure, but in any
case it ought to be possible to make your original document work with no
change to the document. Details to be determined...

David