One way or another, I will make this happen, but I won’t bet on it being pretty or easy to duplicate. And I won’t be able to do much until I have hardware, which will be January for me.
Why does the report get cleared every cycle? It’s really odd to have a function named isModifierPressed() that sometimes tells you the key isn’t pressed when it actually is.
The report gets cleared so we can avoid having to do manual bookeeping, which can very, very easily lead to a whole lot of bugs. And yes, it is odd to have it named like that, and it is something I want to fix. It’s not a trivial task (and switching to manual bookeeping is not an option, not in my book).
Also very interested (on behalf of Kaleidoscope-MacrosOnTheFly) in these kinds of press/release issues
Perhaps it could build the new report without clearing the old one first, and replace the old report by overwriting a pointer in a single step? Or is that what the was*Pressed() functions have access to? (Forgive me; I don’t have time to search the code to figure that out myself right now.)
It is.
(The main use case for the isModifierPressed code right now, is a workaround for a chromeos bug. When called late enough in the flow, it is accurate and useful. I’d argue that the failures folks are seeing with it are due to me not documenting its intended use and what behaviour you should expect from it)
As luck will have it, I just sent in a PR to improve that error message. Jesse wanted it to read slightly differently; I should clean that up and send it back in…
So … any suggestions on how to get so send one unicode when I press fn and another when I press shift + fn?
I tried adding a layer when shift is held in the fn layer, but that doesn’t work for me either …
Can you try if the commented out isModifierActive stuff works, if you change it to wasModifierActive? You can then change the case statements to also have an if (shifted) { /* send uppercase */ } else { /* send lowercase */ } body.
What do you get when you type Fn+shift+unicode macro when using that sketch?
Yes! It works with that change!
Thank you very much. Now I think I have all the pieces to finalize my layout. 
Now I got my initial layout figured and working on my macbook pro, and I have trasitioned to using the model1 instead of the mbp keyboard. It is fun but still learning…
I am going to bring my keyboard to work, where we use windows, so i tweaked it a bit towards that and started testing on my W10 box.
But alas! The unicode input is giving me problems again…
But windows just keeps outputting hex codes :-/
My schetch is here https://github.com/lldata/Model01-Firmware/blob/master/Model01-Firmware.ino
But right now my prime suspect is the windows settings.
http://www.fileformat.info/tip/microsoft/enter_unicode.htm
i’ll try again tomorrow. Meanwhile thanks for all the help in this thread 
Did any of you see any problems with windows and hex unicode input?
I had issues, it worked in some programs, failed miserably in others. I read somewhere that WinCompose might be of help here. It’s also worth checking how the Unicode plugin tries to input Unicode on Windows. I may have screwed that up (I don’t use Windows often).
It looks like the plugin presses alt+u. But the links I found wants alt + keypad_0
Sorry. I meant press (and hold) alt + keypad_plus + hex + release alt.
But it might be worth offering the alt + keypad0 solution as well, since that doesn’t require a registration key to be added …