From a technical point of view
------------------------------
I think it would be nice to have them side-by-side, set up in a way that the effort in ports maintenance can be shared. I can't see the interest in the 32-bit version going away anytime soon, but it may be that we'll see the 64-bit version becoming the standard. The challenge is to come up with a clean way to exchange ports in a multi-architecture system.

At some point in time, we outlined a couple of goals for such a system:
- no untested ports from $OTHER_ARCH should appear untested in $ARCH. Ports should be in $ARCH since they have a maintainer on that platform (I suggested to have a "primary maintainer" for every port, and an "arch maintainer" for every arch; the later would of course be a lot less work, since he/she doesn't have to check for updates or the like)
- no arch specific differences in pkgutils and the port's structure, i.e. the user shouldn't never have to think "oh, I'm on x86_64 so the Pkgfile.x86_64 is overriding Pkgfile in the port directory"
- there shall be no master tree; We can expect that the most capable maintainers for particular ports are distributed amongst the architectures. If we want to improve efficiency by adding more architectures, it must be possible to "track" a master port from any other architecture
- no central commit access needed (this is probably a bit outdated, now that we're using git); porting to a new architecture should not require commit access to a central repository

Maybe with git, there could be a nice way to make these things work; unfortunately, I've not yet found a way to merge only subdirectories (i.e. single ports), but then again I haven't looked in a long time :-).

Definitely an interesting subject, if there's interest from others we should discuss this in mail.


From a project point of view
----------------------------
I think any official crux release should follow the project's goals and guidelines. I'm not sure if we currently have the structures and resources to coordinate such efforts. If any of the $OTHER_ARCH teams wants to push new features which are not used in "regular" crux (like for example PPC does), I'd rather see it as a separate independent project, which is more satisfying for both sides, saving pointless flame wars. Maybe the core team could take act as a benevolent dictator, but I'm not sure if the arch teams would accept its authority.


To summarize, 64-bit support and multi-arch support in general would be a good thing(tm), since
a) it is something I believe could make CRUX a fair bit more attractive to the users (and potential developers) we target, and
b) if an existing maintainer moves to a different arch, his work is not lost
Open questions remain the structure of the overall project as well as the technical approach to ports management

I've been using a multiarch implementation of CRUX for over a year now. In my implementation multiarch ports can either be complete or a subset of the main one, I'm not sure how KISS it is but it works for me.

I prefer to think of my efforts as branching rather than forking ;)

A small update:

Working ISO images of crux-x86_64 can be found at http://www.obra.se/c64. These iso's may contain some minor bugs but should give anyone willing to try a working pure 64bit environment. core/opt ports which require 64bit quirks are maintained in core-x86_64 and opt-x86_64. There are still some ports that require some x86_64-love to build on 64-bit that are not maintained. If anyone would like to help out, let me know.

Is the x32 ABI considered for the x86-64 port of Crux? It seems this ABI provides some interesting speed improvements.

(see https://sites.google.com/site/x32abi/)