While previously Boost.Jam was close to Perforce Jam, it is presently
a permanent and considerably diverged fork. In light of that, what would
be the opinion about renaming 'bjam' binary into something. I don't want
to propose any specific name right now, but I'm interested in the opinion
as to such rename will do more harm than good, or not?

Boost.Build and Boost.Jam IMHO are symbiotic at least until the Python Port is written you can't have one without the other.  I guess you could have some other tool such as Perforce Jam try and parse Boost.Build files, but as is stated it is a divergent fork with enhancements so this working is unlikely.  I haven't tried and don't have the toolset so I wouldn't know for sure.

Here is my understanding of Boost.Jam Boost.Build (and I am probably one of the confused - I think we should aways define what it is we are talking about before we furthur the confusiton - and by all means correct me if I have got it wrong... I probably do not fully understand)

1) Boost.Jam (bjam) is a tool which implements the Jam language (based on the performance jam language) as documented in Appendix A of the Boost.Build user manual (userman.pdf)
2) Boost.Build uses the Jam Language to generate a syntax it uses to parse through Jamfiles and to specify generators for producing output files form source files.  Now whether Boost Build is just considered Jamfiles, or Jamfiles and .jam (including generators and language defifntion) is unclear to me. 
3) Jamfiles contain a syntax for building taking source files and utilizing generators to produce output files.  Jamfiles are parsed by the Boost.Build system (Jamfile syntax) which is implemented in the Jam language.

I think it is easy for users to look at the above as a set of intersecting gray lines.  A build tool love triangle? :-)

If Boost.Build is Just the Jamfile specification then one would be hard pressed to build a Boost.Build qualified tool as one would have to reverse engineer bjam and the jam files to create it.  There is no "specification" that I am aware of such as EBNF specifying the syntax for the Jamfiles.  Is there?

Even from here:
http://zigzag.cs.msu.su/boost.build/wiki/PythonPort/Quickstart
It looks as though bjam is still used?  Or is this a 100% Python app?

I can only guess here , but if another tool (Jam like) such as the phyton port it will be rewritten in Phyton and not have a Python version of Jam tool(capable of parsing existing Boost.Build Jam files), but rather just be rewritten in Python and then there would be another fork? Yes/No? Reference below (PythonPort) says no, but what about when time goes on... would bjam syntax currently in Boost.Build die?  If so I will be the one at the funeral holding the multicolored balloons :-)

I briefly looked at the python port of Boost.Build and It looks as expected: A python port of Boost.Build in Phyton with no references to Jam style syntax, but capable of parsing existing Jamfiles

From:
(http://zigzag.cs.msu.su/boost.build/wiki/PythonPort)

• No user knows that language, making it hard to extend Boost.Build or become new developer <- I can personally totally relate to this having to create my own generators.
  
• The language is strange at times, and not very nicely documented. <- if what is meant by "not very nicely documented" meaning that one had to read the source of Jam and have all the .jam files of Boost.Build open to see "real world examples" of how to use it then yes it is not well documented. ;-)  Then there are those surreal epiphanies one must have when understating how Jam works.
  
• There's no standard libraries, so every new functionality should be implemented from scratch <- For performance reasons it is not clear if this should occur in Boost.Build .jam files or in Jam itself.
  
• The only data structure in the language is list of strings. This makes many tests cumbersome, and leads to excessive memory consumption and poor performance on some workloads. (I got no comment on this one)
  

I would like to add another bullet to the above list and correct me if I am wrong:

Having to:

1) parse through the Boost.Build jam files each time bjam is called is a performance  penalty.  If Jam could create a precompiled cached version of the Boost.Build jam files then some time could be saved.

I think if I understand it correctly the ...patients... comes from the header file scanning.

As with anything, good user documentation can go along way with helping anyone to learn something.  From the user docs I have seen the following reoccur from version to version ( I believe in version 1.34.0 - 1.38.0)