I already sent a note to Paul Mackerras (author and maintainer of
pppd) some time ago, but without any feedback.  So I report this
bug here -- sorry please... :(
Here is my letter to Paul, and a patch that I sent to he.

------------

Here is a patch for two bugs I found in pppd.  One another
issue around this exists but it is not covered by this patch,
since it needs further discussion.
This is against 2.3.11, the same things present in 2.4.0b2.

The problem is that if noipdefault is present, pppd
will ignore local ip address set by local:remote option.
In ipcp_resetci() routine, go->ouraddr reset if disable_defaultip
is true, that's all. This patch modifies logic in
ipcp_resetci(), ip_check_options() and ip_demand_conf() routines
to allow co-existance of noipdefault and local:remote,
and cleans things up a bit.
One another note that in demand mode, if ip addresses are unknown
and initialized to fake values, that fake remote address will be
offerred to other side in ipcp config stage (I'm not shure about
this, since I have no understanding of protocols involved).
Local address will not be offered as a result of incorrect usage
of disable_defaultip variable (yes, again this!), but remote will.
Some background about this.  disable_defaultip used to hold presence
of noipdefault option (btw, why not name variable and option in
consistent manner, so that will be less confusion/errors?).  That's
ok.  But also, it is incorrectly used in demand code (and in
ipcp_resetci()) to mark that local address is fake one, to stop
offering it to other side.  This is the cause of the first problem.
I added two bools to ipcp_options -- disable_offer_{local,remote}
that are set to true if corresponded address is fake in demand
mode and checked by ipcp_resetci().  With this, disable_defaultip
used only as option value. 
With both this, noipdefault will not stop usage of local: address,
and fake (both remote and local) addresses will not be requested
from remote side.

One little (but about security) question around.  Is local:remote
option privileged?  If no, than setting noipdefault will prevent
user(s) to use it as a side effect of this bug, and a long as it
is corrected, users will be able to set up any address(es) of link,
that is not so good.

And the issue that is not covered by patch.  In demand+persists
mode, and when no local/remote addresses given, should pppd
ask remote side to use previously assigned addresses?
I.e., consider this sequence:
  1. pppd started, interface with fake addresses set up
  2. packet to interface arrived, pppd dialed and assigned real
     IPs (not asking peer to use tha fake addresses), say LOC:REM.
  3. link was terminated (due to lack of activity or modem disconnect)
  4. pppd dialed again.
At this point, should pppd request peer to use LOC:REM, or it should
not request any addresses?  As a side note -- if the firstly assigned
say local address was not fake (i.e. given in parameters), then
I think that in point 4 pppd should again request it and not LOC that
was used (assuming that ipcp-accept-local is set).  But if local was
fake first, then probably pppd _should_ again request LOC
(the same is for remote address and REM).
What do you think about this?

And -- here is some other issues/questions/proposals, "as usual" :).

I looked for inconsistent "local:remote" option.  Why not give it a
name, say, "ip" (as for "ipv6")?  The old syntax shoud be preserved
but not encougraded.  This is a trivial change for first look, but
not for second.  Almost all ip-related options handled in ipcp.c
file, but some of them are in options.c, and local:remote (and
netmask) is here.  Best solution is to move rest of ip-related
stuff into ipcp.c, but in this case things will be harder.
Note that ipv6 syntax is differ from "ip" syntax (delimiter in
first is comma, in second is colon).  This probably should be
fixed also.

Also, with other "unnamed" option (device, speed and netmask) --
will it be better to give them names?

As a side effect with all this, it will be a bit easier to allow
supporting of more than one link by one pppd process (*cp.[ch]
and others are ready for this, but options.c is not).

I can produce trivial patch for options.c but it will be a "partial"
solution, so I not done this already -- I want the "ConfAck" from
you here.

And a hardest part for the end.  I have some modems attached to one
machine and them are used both for dial-in and dial-out, and sometimes
need to handle some number of simultaneous incoming connections and
some number of outgoing (some of them should also be multilinks, but
for this I'm waiting for linux 2.4).  So, for dial-out, I need to
choose the first available modem.  But pppd requires to specify one
dial-out device at a time...  I think that you understand the rest of
problem :).
Currently, I have a script that finds the first available device using
external program to lock it (cutted from ppp's utils.c) and then execs
pppd with right argument (with lock "already held" by it).  This is a
bit ugly since pppd was designed so that it handles all the cases on
it's own acting as true "master" not a "slave" (it executes tty process
itself for example).
I looked to source and found that allowing more than one device
in command line is not implementable easily.  I can implement
this, but again, I need some acknolegement from you here.

Thank you!

Regards,
 Michael.