Q:

Modified Colemak for Programming

Does there exist a modified Colemak keyboard layout designed specifically for programming?
I went cold-turkey on the Colemak keyboard layout a few days ago and I really like it for normal typing, but I have some issues for frequent programming characters like the ; (semicolon) key. A modified layout that has direct mappings for braces and parentheses would be nice.
Obviously I could remap these keys myself via trial-and-error, but I'm hoping someone has done some testing to determine an optimal layout for common language characters.

A:

Background
This is me doing an hour and a half presentation on keyboard layout history and theory: https://www.youtube.com/watch?v=i1hK1qrdYtU
I take this very seriously, and am constantly experimenting. I am obsessed with efficient working, and I have manifested very compelling results, such to say, I guarantee it is very much worth the endeavour. 
In my answer, I will be going more over theory as my layouts are primarily tailored towards my specific programming needs, and would be unsuitable for say, a Python Developer unless he adjusted the bigrams and Level 1 characters.
Use the theory, and tweak it to your needs.
Terminology:

Altgr: Usually the right alt key enabled for you to write foreign characters or accents.
Level 1: Layout with no modifier keys (Shift, Altgr).
Level 2: Layout with Shift
Level 3: Layout with Altgr
Level 4: Layout with Shift + Altgr

Beta Keypad-Vim Programmer's Colemak v3
This is a right oriented layout that I WAS using for the past year:

Keep in mind, this layout was optimized for:

vi (Notice how the directional keys are on the right hand, just like vi)
C Languages
APL (Yes, APL)
XML (Secondary consideration)
Bash (set -o vi)

It encompassed three main radical theories on keyboard layouts:

Directional Keys Up Down Left Right Home End PgUp PgDn should be delegated to Level 3 all in reach to your natural finger placement. 
Both Alt keys should be turned into Altgr, so you can access Level 3 with either hand.
Numbers should be taken off the top row and organized into a keypad. Common calculator symbols should surround it. 

It also should be said that programmers layouts by principle move numberkeys off Level 1, because a good programmer should not be using Numbers very often at all. See: https://en.wikipedia.org/wiki/Magic_number_%28programming%29

Here are how the theories played out over a year of use:
Theory 1 - Directional Keys
EXPLOSIVE IMPROVEMENT TO ENTIRE WORKFLOW, especially document editing (as opposed to Programming where vi already provides that functionality)

Home and End keys are extremely useful when put into proper reach. 
The directional keys are indispensable. 
PgUp and PgDn are underused, however this could be because of the lean the staggered keyboard places, making you have to stretch for Prior. Currently testing this reversed on left hand (Pictured at Bottom of this answer.)

Theory 2 - AltGr
This was a necessary requirement, in the same vain that we have two shift keys, two altgr keys are situated to the immediate left and immediate right of the spacebar. Working with just one would make typing a painful process. 
While necessary, it is important to mention that some very minor pain could develop with the thumb pressing down on them so often. A small price to pay. If you could get a shrunken spacebar layout, such as:
This would probably solve the issue. 
The other issue, which would be huge for most users, was lacking an alt key. However on Ubuntu, you can access most menu commands using the HUD which eliminates the need for 90% of the keyboard shortcuts that would use Alt. The only the issue I would occasionally have is not having access to TTY terminals. (Alt+Ctrl+F1) I never bothered remapping it, although I should.
Theory 3 - Number Pad

This was a tough one, namely because of its left orientation. On previous versions, I experimented with moving the keypad up one level so that 0 and 1 would be on the home row, and with the number progression reversed (Notice how it goes 3210 instead of 0123).
Ultimately I have come to prefer it, but the adjustment was pretty arduous because:

Muscle memory for keypads is most often with the Right hand.
Horizontally staggered Keyboard Layouts (Which are fantastically stupid. See my youtube video), make for a challenging Number Pad, although I worked out the best compromise.
The reverse order of the numbers, which was necessary because you want 0 and 1 (Most common) accessible by your index finger.  

At the end of the day (and many months of adjusting to it) I do prefer it although I feel it is only 40% as good as it could be. More importantly though, I discovered a few things:

+ was actually easier to type on Level 3 then having it on Level 1 off in its corner or even on the top row.
The . was incredibly useful on b

With all that in mind, I have decided to experiment by switching the number pad to the right, and the directional keys to the left. In this orientation, I will go over the many little improvements not mentioned, and over my major new theories.
Beta WADS-Keypad Programmers Colemak v1

Optimized for:

C Languages (); // << "" \n \t m_
Bash / "" < * && || \ \( \) ^C
Document Editing ? ! Shift_R Control_R 

Holdover Theories:

Reverse Brackets: The orientation of () being changed to )( is greatly preferred. This is part of basic Colemak theory which states that it is easier to roll your fingers from pinky to thumb. (Colemak is a layout that emphasizes finger rolling over hand alteration, which Dvorak prioritizes). Especially useful for this extremely common C++ trigram (); It was surprisingly easy to get used to, even though it seems backwards.
Level 2 mostly untouched: This is just for practical adjustment. It is not a terribly important layer, so it is maintained for muscle memory.
Control between shift and z: The best mod. Copying, Pasting, Select All, and Undo are no longer painful and awkward, and are now a simple finger roll.
Return on Level 3 right pinky: In vim, o creates a new line. It made practical sense to place a Return on this key for text editing. It turned out to be very convenient and it quickly became muscle memory. 
Double-quote middle finger: Its criminal to have the double quote on level 2. I found much satisfaction having it up on the easiest to reach top row key, 4.
? on level 1: Man I love this. Not having to finish with hand shifting key combo is heaven for writing documents.

New Theories

The pinky should never touch the spacebar row, or even the shift keys: The benefits of moving that control key up one level convinced me absolutely of this. (Note, I have a french layout which turns the left shift into two buttons.) After all, this is what the dreaded emacs pinky is developed by. As such, a shift key has been placed on the home row. While I was tempted to also turn Capslock into a shift key, and move backspace to Alt+D, I am going to just stick with the shift key right of o. In my short experience, I already love it there, and do not miss whatever I had there before. 
You should never end a statement, paragraph, or Sentence on Level 2: Because of my great success with ? on Level 1, I have decided to put the ! there too, albeit in the far corner. I moved it to the far corner because it is not that common, and ¬ and ~ are both representative of false/not statements. != ~Deconstructors (P & ¬Q). The main thrust though is that you should be able to complete a statement, paragraph, sentence, etc without having to do a key combo, as this disrupts flow.
Utilize WADS muscle memory: While vi has you doing directions on your right hand, anyone who has played a videogame is accustomed to do movement with their left hand, so it should follow that it is perfectly saleable to do movement with the left hand. Will be remapping Vim however to follow suit with this, which will take some adjustment. 
Keypad should only be on the right hand: As said before, this visually makes more sense, keeps 0 and 1 on the index finger, and takes advantage of muscle memory developed from using a keypad.
Escape on Level 3 a: We'll see how this develops. I had tried it on the tilde, but usually forgot it was there. As a vim user, I do need Escape quite a bit, but usually I mitigated that need by mapping inoremap so Level 3 directional keys would escape (and move the cursor) when pressed.
Level 3 C and V should be filled with a very common non-alphanumeric bigram: At the moment, I have it with */ as this is important for commenting, but it could be filled with many different things. 
& on Level 1 in its shift position: The most frustrating character ever to try and press while doing shift. Same goes for the ^ which I would use a fair bit in regular expressions. If you rely on these at all, you need to find a better place for them.
Will try Insert and Delete on Level 3 Z and X.

Everything else is basically just trimmings. Again, you move them depending upon your usecase. A python developer might want to put the : on level one, and situate it to combo with a Return.
Failed Theories

Shift + Backspace should perform a Delete: Way too confusing and never useful.
78 /* bigram: This one was not actually that bad, but it was not terribly useful given the bigram goes both direction. It also required a significant stretch. I think it would be better to have the characters on each hand so it is easier to combo them both ways.
Tilde Escape: Just under utilized. If you are going to stretch that far anyways, might as well hit the escape key, which I frequently did.
{ } on Level 1 right hand beside enter, not reversed: This was a horrid and frankly painful bigram, very awkward to perform in case you ever needed a {}. Better place for single unrelated characters (ie, two characters you would not push in succession)

Building Your Own Custom Layout
https://docs.google.com/spreadsheets/d/1LkvWvwjahVaJyaN9hmDdulrAN08x7gQEM6DT4NFkok4/edit#gid=507511935
I have created this spreadsheet which will generate the appropriate xkb code for insertion into a layout. Just:

Change the characters on the Layout Definition Page
This will convert characters to unicode which are concatenated into xkb code.
Go to the XKB page, and select the rows, and insert them into your layout.
Properly go about adding a new layout.

Now, creating a proper layout is actually pretty difficult, so I just replace what is already in the colemak definition (BACKUP FIRST,  if you make a mistake, you will not be able to type at all, and might even need a live boot to fix the issue.)
and it looks like this:
sudo vim /usr/share/X11/xkb/symbols/us

// Colemak symbols for xkb on X.Org Server 7.x
// 2006-01-01 Shai Coleman, http://colemak.com/
// Akiva Abraham WADS-Keypad Programmer's Colemak

partial alphanumeric_keys
xkb_symbols "colemak" {

include "us"
name[Group1]= "English (Colemak)";

key <CAPS> { [    BackSpace,    BackSpace,       BackSpace,        BackSpace ] };
key <LSGT> { [Control_R, Control_R, Control_R, Control_R] };
key <SPCE> { [        space,        space,           space,     nobreakspace ] };

key <TLDE> { [U0021, U007E, U00AC, U00A4] };
key <AE01> { [U005B, U0021, U005B, U20AC] };
key <AE02> { [U005D, U0040, U005D, U00A2] };
key <AE03> { [U002F, U0023, U002F, U00A3] };
key <AE04> { [U0022, U0024, U0022, U00A5] };
key <AE05> { [U003C, U0025, U003C, U003C] };
key <AE06> { [U003E, U005E, U003E, U003E] };
key <AE07> { [U0026, U0026, U0026, U2030] };
key <AE08> { [U002A, U002A, U002A, U00BC] };
key <AE09> { [U0029, U007D, U0029, U00BD] };
key <AE10> { [U0028, U007B, U0028, U00BE] };
key <AE11> { [U005F, U005F, U002D, U2308] };
key <AE12> { [U003D, U002B, U003D, U230A] };

key <AD01> { [U0071, U0051, minus, U00A9] };
key <AD02> { [U0077, U0057, Home, U00AE] };
key <AD03> { [U0066, U0046, Up, U2191] };
key <AD04> { [U0070, U0050, End, U00B6] };
key <AD05> { [U0067, U0047, Prior, U2371] };
key <AD06> { [U006A, U004A, U0023, U2372] };
key <AD07> { [U006C, U004C, U0037, U00B0] };
key <AD08> { [U0075, U0055, U0038, U22A4] };
key <AD09> { [U0079, U0059, U0039, U00A7] };
key <AD10> { [U003B, U003A, U2234, U2234] };
key <AD11> { [U005C, U005C, minus, U0025] };
key <AD12> { [U007C, U00A6, U007C, U2262] };
key <BKSL> { [U0027, U0060, U0060, U2260] };

key <AC01> { [U0061, U0041, Escape, U2122] };
key <AC02> { [U0072, U0052, Left, U2190] };
key <AC03> { [U0073, U0053, Down, U2193] };
key <AC04> { [U0074, U0054, Right, U2192] };
key <AC05> { [U0064, U0044, Next, U2228] };
key <AC06> { [U0068, U0048, U0024, U2227] };
key <AC07> { [U006E, U004E, U0034, U22A3] };
key <AC08> { [U0065, U0045, U0035, U22A5] };
key <AC09> { [U0069, U0049, U0036, U22A2] };
key <AC10> { [U006F, U004F, Return, U2235] };
key <AC11> { [Shift_R, Shift_R, Shift_R, Shift_R] };

key <AB01> { [U007A, U005A, Insert, U2229] };
key <AB02> { [U0078, U0058, KP_Delete, U222A] };
key <AB03> { [U0063, U0043, U002A, U2282] };
key <AB04> { [U0076, U0056, U002F, U2283] };
key <AB05> { [U0062, U0042, U002E, U2022] };
key <AB06> { [U006B, U004B, U0030, U00BA] };
key <AB07> { [U006D, U004D, U0031, U00B9] };
key <AB08> { [U002C, U003C, U0032, U00B2] };
key <AB09> { [U002E, U003E, U0033, U00B3] };
key <AB10> { [U003F, U003F, U002F, U2020] };

include "level3(ralt_switch)"
include "level3(lalt_switch)"
};

