I've used many SCM's over the years and they universally expose stupid, clunky, difficult, and overly complex user interfaces. For day to day use most people only need check out, check in and undo checkout, but the SCMs permanently expose hundreds of options. I agree totally with your desire to have something simple to use (with an advanced UI for those times when you need to do something more involved)
I have aso implemented three bespoke SCMs ("wrapper" UIs for SourceSafe and Perforce, and finally a fully blown bespoke SCM based on an SQL database - these were used on several game projects with up to 100 concurrent users).
If you want a "simple" SCM, then your best approach is to take a solid and well supported SCM and write a client application as a simplified front end for it. Most if not all SCMs expose an API that allows you to control them. Writing a good front end you need only expose the basic operations:
- browse files
- check out
- check in
- undo check out
Whenever you need to do anything more complex you can resort to the SCM's more complex user interface - there are times when the more complex UI is needed. But most of the time your simple UI will be perfect.
Bear in mind that if you want to add more features but keep things "simple", then you're in for a whole load more work. For example, in a "simple" branching system, you would just create many "variants" of your source code (branches), and by choosing the active branch from a list, the SCM would automatically switch you between them. Simple UI, but this would take a lot of work to implement - hence we're stuck with overly complex branching systems involving hideous workspace mappings that have to be set up on every user's PC.
If you want to roll your own SCM from scratch then beware: It is a lot lot lot more difficult and time consuming than it looks!
Version control for a single user is trivial to implement (you need a file storage system that records historical versions, and a way of copying files between your workspace and the version-store (but you'll need a good mapping approach so you can rename and delete files without losing their history). Rolling back is as simple as fetching a historical version and then checking it in as the new "latest version")
Then labels are really useful. They're easy to add.
Then you really ought to add changelists so you can check in a group of files as a related change. Not quite so simple as they might seem because for reliability you really want to make each checkin an atomic transaction, so that you don't get a partial check-in if anything fails.
As soon as you go multi-user, you introduce concurrent network access and locks - this is suddenly several orders of magnitude more complex. You need a database to remember which files each user has in their workspace and who has what locked, and a very robust means of handling concurrent checkins (so the database can handle e.g. two checkins of hundreds of files simultaneously without corrupting anything).
Then you need to support operations like Add and Delete which are only applied locally until you check them in. So you need a local database to store the current state on each user's PC.
Then we have a system where only one person can change a file at a time. If you want non-exclusive locks, you need to support 3-way merges.
And then there's branching, with some way of configuring workspace mappings.
If you need internet access rather than LAN access, you might need to add some form of proxy/replication system.
And... Oh, we've got a hideous complex beastie with a clunky complicated UI. And we're so busy supporting it that we don't have time to go back and write a nice simple UI for using the basic features. :-)