@mweise, it sounded like a straightforward bit encoding task, but as you can see when implemented using completely standard libraries as a one-liner in Python, the results are different (due to the order of bits). A lack of clarification of byte ordering results in this problem. You can see the code that shows standard libraries output something else here.
You can see that the Wikipedia article on base64 encoding also specifies:
Groups of 6 bits (6 bits have a maximum of 26 = 64 different binary values) are converted into individual numbers from left to right …
This base64 conversion website also confirms that encoding is left to right.
Therefore, a clarification that the base64 encoding deviates from the standard and instead is done right to left should be documented.
@aothms 's explanation also specifies some rules which are clearly not as simple as a standard base64 encode, which is what the documentation currently implies.
In addition, clarification on which UUID generation algorithm is preferred or suitable should be made on that page. I have seen IFC files created where the UUID is clearly an incrementing number and not random. I believe this is not a good thing, as it creates potential for collision in a future where we might have city-scale BIM datasets, but without any mention of it in the official buildingSMART documentation, I have no official source to turn to.
As a bonus, an explanation on why buildingSMART decided to use a non-standard base64 character set would be good. It always seemed very strange to me since base64 has been around forever.