OK, after all I managed to overcome my concerns and I started working on it (I mean adding the additional sign bit to internal calculations).

rb 100
store qword -1 at 0
load x qword from 0
if x = -1
    display 'Consistent store-load',0
else
 display 'Inconsistent store-load',0
end if
    

macro signExtend.dword v.out, v.in {
    v.out = v.in or ((v.in and (1 shl 31)) * (((1 shl 32)-1) shl 1))
}    

l_inc, If you replace all the occurrences of qword with dword you'll get 'Inconsistent store-load' message too even with the current fasm version.

Perhaps it is time to introduce yet another feature like "load signed ..."?

x = -1
store qword x at 0 ;we lost the extra sign bit, the hole was not big enough to take the full number
store byte (x shr 64) at 8 ;if we need the sign bit then we gotta store it somewhere!    

You are trying to squeeze a 65-bit value into a 64-bit hole.

Code:

store byte (x shr 64) at 8 ;if we need the sign bit then we gotta store it somewhere!    

dq x
load y qword from $-8    

;Displays a decimal representation of a number
macro dispDec num*, padding, leader, trailer
{
      local digCount,tenPow,number

    number = num
        virtual
             dq number
           load number qword from $$
   end virtual
 if number < 0
            display '-'
               number = -number
    end if
      digCount = 0
        tenPow = 1
  while tenPow <= number
           tenPow = tenPow*10
          digCount = digCount + 1
     end while
   if digCount = 0
             digCount = 1
                tenPow = 10
 end if
      if ~ leader eq
              display leader
      end if
      if ~ padding eq
             if digCount < padding
                    times (padding-digCount) display '0'
              end if
      end if
      repeat digCount
             tenPow = tenPow/10
          display number/tenPow + '0'
               number = number mod tenPow
  end repeat
  if ~ trailer eq
             display trailer
     end if
}    

Adding the 65-th bit is going to clean up some quirks in which DQ behaved differently from DD/DW/DB

It may break some things if someone misused the old QWORD bugs.

However the above macro will still do exactly what it does now, it will display the value of 8 bytes generated with DQ directive.

and you already loose some information, like relocation (if the value is relocatable then such display is not very useful, since you no longer know what is it relative to)

;allows to define a sorted array of signed dwords
macro ddSorted [vals*]
{
    common local count,qw1,qw2
          count = 0
           virtual
     forward
                     dq vals
                     count = count + 1
   common
                      repeat count-1
                              repeat count-%
                                      load qw1 qword from $$+(%-1)*8
                                      load qw2 qword from $$+%*8
                                  if qw1 > qw2
                                             store qword qw2 at $$+(%-1)*8
                                               store qword qw1 at $$+%*8
                                   end if
                              end repeat
                  end repeat
                  count = 0
   forward local newvals
                       load newvals qword from $$+count*8
                  count = count + 1
   common
              end virtual
 forward
             dd newvals
}    

v1 ;value1
v2 ;value2
;signed compare
  if v1 > v2 ...
;unsigned compare
  if (v1 xor (1 shl 63)) > (v2 xor (1 shl 63)) ...    

There has been never provided a definition for use and misuse. Especially because (as you also said) there were found (and became standard) interesting usage examples for directives never intended for those purposes.

Doing the same means to return same result for any usage. It won't return the same result for dispDec -1, will it?

Will it give the same result for the code ddSorted -2,2,0,+1,-1 as now? Or is the compilation going to fail? Any ideas of how to achieve the same with the new fasm behaviour?

revolution
I assume, you didn't understand the operation. The sign is not defined by the MSB.

;65-bit
-2 = 0x1fff...ffe 
-1 = 0x1fff...fff
 0 = 0x0000...000
+1 = 0x0000...001
+2 = 0x0000...002

;64-bit (like now)
-2 = 0x0fff...ffe 
-1 = 0x0fff...fff
 0 = 0x0000...000
+1 = 0x0000...001
+2 = 0x0000...002    

dq -(1 shl 63+1) ;What will happen? It should give an error    

Code:

dq -(1 shl 63+1) ;What will happen? It should give an error    

revolution, I'm sorry, your macro will probably not work because of this.

macro signExtend.dword v.out, v.in {
    if ~ v.in and 80000000h
      v.out = v.in
    else
      v.out = v.in and 7FFFFFFFh - 80000000h
    end if
}    

macro def [name, size]
{
   macro signExtend.#name v.out, v.in
   \{
      v.out = v.in or (0 - v.in shr (size - 1)) shl (size - 1)
   \}
}

def byte,  8,\
    word, 16,\
   dword, 32,\
   qword, 64

purge def