Ls colors: why are some of the fonts black and others green in ls output

You've misinterpreted the primary rationale for "hidden files". It is not

to prevent users from messing around with things.

Although it may have this consequence for very new users until they learn what a "dot file" is (dot file and dot directory are perhaps more appropriate and specific terms than "hidden"). All by itself it doesn't prevent you from messing around with things -- that's what permissions are for. It does perhaps help to indicate to new users that this is something they should not mess around with until they understand what it is for.

You could thus think of the dot prefix as a sort of file suffix -- notice they usually don't have one of those, although they can. It indicates this file is not of interest for general browsing, which is why ls and file browsers usually will not display it. However, since it's a prefix instead of a suffix, there is the added bonus, when you do display them (ls -a) in lexicographical order, to see them all listed together.

The normal purpose of a file like this is for use by an application (e.g. configuration). You don't have to use them directly or even be aware of them.

So, this "hiding" isn't so much intended to literally hide the file from the user as it is to reduce clutter and provide some organization conceptually.

That library has a main() function or equivalent entry point, and was compiled in such a way that it is useful both as an executable and as a shared object.

Here's one suggestion about how to do this, although it does not work for me.

Here's another in an answer to a similar question on S.O, which I'll shamelessly plagiarize, tweak, and add a bit of explanation.

First, source for our example library, test.c:

#include <stdio.h>                  

void sayHello (char *tag) {         
    printf("%s: Hello!\n", tag);    
}                                   

int main (int argc, char *argv[]) { 
    sayHello(argv[0]);              
    return 0;                       
}                   

Compile that:

gcc -fPIC -pie -o libtest.so test.c -Wl,-E

Here, we are compiling a shared library (-fPIC), but telling the linker that it's a regular executable (-pie), and to make its symbol table exportable (-Wl,-E), such that it can be usefully linked against.

And, although file will say it's a shared object, it does work as an executable:

> ./libtest.so 
./libtest.so: Hello!

Now we need to see if it can really be dynamically linked. An example program, program.c:

#include <stdio.h>

extern void sayHello (char*);

int main (int argc, char *argv[]) {
    puts("Test program.");
    sayHello(argv[0]);
    return 0;
}

Using extern saves us having to create a header. Now compile that:

gcc program.c -L. -ltest

Before we can execute it, we need to add the path of libtest.so for the dynamic loader:

export LD_LIBRARY_PATH=./

Now:

> ./a.out
Test program.
./a.out: Hello!

And ldd a.out will show the linkage to libtest.so.

Note that I doubt this is how glibc is actually compiled, since it is probably not as portable as glibc itself (see man gcc with regard to the -fPIC and -pie switches), but it demonstrates the basic mechanism. For the real details you'd have to look at the source makefile.