Sounds like a great idea.  Would be interested in reading articles on some of the topics mentioned.  Sites like suckless.org state what they consider are better and worse software choices.  Would be nice to see some actual statistics and rationale backing up what is considered better or worse design.  For instance, there are some negative mentions about the PCRE library, but when I tried to track down the cons for using it, I only found dated performance comparisons showing how poorly it worked if you don't use the newer JIT implementation.  What might be a positive for a system that's optimized for a particular processor might be a negative if you're interested in software that ports to multiple processors and vice versa.  Musl's useful not just for embedded systems but for older machines that want to run efficient desktop environments.  However, what works for a desktop environment might not work well for an embedded system and so on.  Would like to see actual lists of pros and cons, less opinions and let the user decide if the software is really a bad fit with his/her needs or not.

Would also love to see a forum where one could discuss pros and cons of various software and library choices, alternatives already out there and if the user wants to rewrite some of these himself or herself for specific needs, a place to discuss design issues.

There is an lfs-chat list.  Think it would probably be a good idea to post something about the idea of an LFS for embedded systems there and see if any of the regular LFS users would be interested in getting involved.  A start might be to take the outline of possible topics Rob Landley supplied, put it up on a wiki and see if people will volunteer to fill in some of the blanks.  Might also be useful to get together a list of what tasks need to be done to get something started and ask for actual volunteers for each task to help get things rolling.  I do think a mailing list or forum would be useful as well.  That way, one can get discussions going and brainstorm ideas about how best to program something or find information on a topic.  I tend to prefer mailing lists and forums to IRC.  It's easier to read through past information.

I've been talking with another developer about the possibility of building (yet another) lightweight Linux distribution for older machines.  I really haven't been happy with what's currently out there.  The average definition of a lightweight Linux desktop for older machines is to use a lot of GTK+ programs (with a lightweight desktop like XFCE (not my definition of lightweight), LXDE or razorQT) and even interpreted programs (as long as they look like they're in console mode or like they might somehow be lighter or more useful than their compiled equivalents).  They typically use the KISS principle which means (according to their take on it) I'm stuck with the one graphics editor, the one music player, etc. that the distribution creator happens to like.  A Gimp or a Photoshop style program has a lot of functionality.  So does an Office Suite like LibreOffice.  If you're going to replace heavyweights with a program that does one thing well, you're typically going to need more than one application with each application designed to perform a specific piece of the functionality well.  You need more than one type of graphics program if you're doing serious graphics editing, more than one type of music program if you're doing serious music creation, etc.  A lot of the topics such as how to put together a system from scratch, what boot and init programs to go with, which userspace utilities to use, which package manager to use, which libraries are efficient would be of great interest for the project.  Another concern to me is which projects are open to accepting patches and which aren't so open, making it prudent to look into more friendly alternatives.  I'd also been interested in discussing when it pays to rewrite something from scratch and when it's better to reuse what's already been done.  I've been picking up ideas by looking at the code embedded systems use.  However, the end goal for this particular project is not an embedded system but a GUI desktop that an average end user will be comfortable working with.  There's a lot of overlap, but definitely different goals with different design tradeoffs.

Hope the idea to document and share many of the topics mentioned takes off.  Think it would make a very nice resource for certain types of developers.

Sincerely,
Laura
http://www.distasis.com/cpp