Background: we need to support sealed types, for that we must allow classes to be final. Current behavior for top-level modifiers is that "final" and "static" are ignored, with a warning; "abstract" is an error for variables and methods; and "static" is ignored with a warning.

It is guiding principle of JShell that as much pasted Java code should work. Additionally, unnecessary warnings are a distraction. Jan has pointed out some possibilities for improvement, as we investigate how the modifier changes are handled and implemented.

Let's step back and look at the space...

"final", "abstract", and "static" are the interesting cases. Let's look at the options:
    
variable
    final: ignore with or without message or allow
    abstract: error (JShell or compiler)
    static: ignore with or without message
method
    final: ignore without message or allow
    abstract: error (JShell) or ...
    static: ignore with or without message
class
    final: allow
    abstract: allow
    static: ignore with or without message

Case by case:

abstract
-----------

variable: abstract is not allowed on variables in Java. Currently a JShell error is generated. Seems using the compiler error would be superior.

method: there is no way to implement/override a top-level method and the top-level is implemented static, which can't be abstract, so generating an error kinda makes sense on that level. It can't be ignored, because there is no body. But in support of pasting code and allowing code to evolve, it could have a body generated for it that, if called, aborts with a message just as methods with an undefined identifier in the body behave. This is probably out of the immediate scope of this investigation.

class: abstract classes must be and are allowed

final
------

variable: final variables have been ignore because it prohibits modifying the value -- which when exploring code is important. This is almost certainly overkill protective padding. It interferes with pasting, including constants. Allowing final seems the best option, as a new user can see the semantics. The declaration can always be overridden without the final. Ignoring without a message is another option, but this could confuse new users and also violates Java semantics.

method: final methods have also been ignored with a warning, and that is just silly in retrospect. They can't be overridden, so there is no way observe the semantics. They should be allowed (or ignored with no warning, as that is equivalent).

class: final classes haven't been allowed, again overly heavy-handed attempt to allow modification. And now, we must have final classes for sealed classes.

static
-------

All definitions are implemented as static. They have been ignored with warning, on the fear that user's would attempt to ascribe meaning to them. My guess is the warning (esp. in a paste case) is more pain than value. And just confusing to a new user. Or...

-------------

Note: the "final" portion of this has been handled under JDK-8246353