PowerFlarm and ADS-B solution, can we find one?

I think it is time to end this back and forth ping pong about restricting the use of PF. We have to agree to disagree and try to come up with a solution that could work for both groups.
Let's try to define some criteria that might be acceptable to all:
1) Should targets be visible on PowerFlarm display?
2) If (1) is "Yes" then what is the desired distance at which targets should be visible on PowerFlarm display?
3) Do we allow for displaying altitude of another glider on PowerFlarm display?
4) Do we allow for displaying information pertaining to climb rate or simply indicate if a glider is ascending or descending?
5) Do we need to be able to identify a conflicting glider?
6) What are the minimum requirements for identification of conflicting traffic?
7) Should we aim not to degrade PF functions for non-contest participating PF users in the area of a contest?
8) How do we deal with ADS-B in a glider? I have ADS-B out plus I have ADS-B in on both 1090 and 978.
9) Anything else?

(1) I suggest "Yes" otherwise there is no situational awareness at all:
a. In my opinion some situational awareness in the vicinity is required
b. one evasive action can cause another dangerous situation
c. it is very stressful to be reacting to sudden alarms without prior awareness of where the traffic might be coming from and this can lead to development of other dangerous situations
(2) Let's do some math. Two gliders on traveling in opposite directions at 17k feet can easily be closing distance at the rate of 260 kts. Let's remember about TAS at high altitude. That is almost 500 km/hour. Let's use the 60 seconds as an adequate awareness time. This leads to a distance of 8km. If we desire to use 5km as a minimum than we have 37 seconds of advanced warning. Is that enough? Each of us will have different criteria. I think 37 seconds might be enough for me if I am rested and there is good visibility. Let's remember it is not only reaction time but also achieving meaningful separation, and knowing which way to turn and then maybe have some room for a mistake (like turning the same way for by gliders)
(3) I think I would like to know altitude difference and if traffic is climbing or descending or just altitude. I really don't care much about what the rate of change is.
(4) Answered above
(5) Initially I thought this was not required but I think being able to communicate might be important in some situations.
(6) I do not think we need contest ids we could create another way of identifying gliders, however with time people would figure out what the opponent codes are if they really wanted to.
(7) Absolutely "YES" This is where "Stealth" mode fails.
(8) I have seen power traffic cruising happily under cloud bases. That is why I have ADS-B out and I also have ADS-B In on both 1090 and 978. I get traffic from ground stations. I put the ADS-B out so I can see the power traffic around me and not to freak out every time I see a ring on PCAS not knowing where the traffic is. The only way I see we could control ADS-B in is if PowerFlarm updated its ADSB-in to include ground station transitions, which I thought they did, but maybe not. Then we could limit ADS-B traffic to 5 km, which could be a huge mistake because at 17k feet power traffic can go really fast. This is a real problem. Additional ADS-B in equipment I have in my glider to receive ground station traffic cannot be limited to 5km. I would be willing to get the other equipment out of my glider as long as I get traffic transmitting by ground stations on PF, but what to do about fast power traffic? Anyone has a good idea? Filter based on speed?
As you can see, complexity of working out a solution is huge as there are many variables. We would need to deal not only with flarm traffic but also with ADS-B traffic and consider you might deal with high speed ADS-B traffic..

Let's see if we could agree on technical specifications for future competition mode that would be acceptable to everyone, but it needs to include ADS-B in. I am not sure there is a solution, but let's try.

Let's give each other some room and that includes RC. It would also be nice to get a briefing from RC where things are with Flarm and what is being considered by Flarm. Lastly as you can see there are many variables. It would be nice if we could agree to not attempt to make any changes for 2016 and instead spend time trying to figure out what a solution should be and test it properly. Again, a solution should meaningfully deal with ADS-B.

I hope we could keep this thread focused on a solution and not question our positions. We have done enough of that.