ShellLineInterpreter.interpretLineType returns SQL_BUFFER_CMD for this line (\\echo hello > ), which prevents autocompletion for files and directories.

There are a couple of things we need to look into:

(1) In fluid shell, auto-completion is determined by command, not by shell.  There is a set of attributes in the command object which tells shell whether auto-completion should be performed and how. When a command name is typed, followed by a space, then a tab key, fluid shell will check the auto-completion related attributes associated with the specified command, if a match is found, the auto-completion is performed; otherwise, nothing would happen. These auto-completion attributes are hard-coded at command implementation time, cannot be changed at run time.

Many fluid shell commands have NONE of these auto-completion attributes turned on, for examples: echo, history, alias, just name a few.

In bash, commands such as echo, history, alias, etc. will perform auto-completion when asked; echo and history will display the matched files, alias will display the matched commands.

=====> We should review all of fluid commands and turn on auto-completion related attributes based on bash behavior.

(2) Things getting complicated when input consists of pipeline (i.e. | character) and/or redirection (i.e. >, >>, etc.) and/or command separator (i.e. ; character) because SQL statements can be involved in such cases. For examples: 'select * from table / | tee <tab>'.

In the current fluid shell implementation, auto-completion handler uses bash's parser to parse user's input. If parsing succeeded, further checks will be performed in order to determine how to proceed on auto-completion (see next paragraph); if parsing failed, a default behavior is set based on the value of CLI_SHELL_LINE_INTERPRETER_IMPLICIT_BEHAVIOR shell variable (see last 2 paragraphs).

If parsing performed by bash parser succeeded, further checks need to be performed in order to determine how to proceed on auto-completion because there could be SQL statements involved. Example 'select * from table / | tee <tab>' mentioned above is a typical example.
For this sort of auto-completion, below are some examples that fluid shell currently can handle:
    select * from table / | tee <tab>
    select * from table / | tee prefix<tab>
    select * from table / > <tab>
    echo 123 ; cat <tab>
=====> here are some examples that current implementation cannot handle:
    select * from table / > prefix<tab>
    select * from table / ; cat <tab>


>>>> either nothing happens (ie, no Autocompletion window appears),<---In case the current FluidShell tab is NOT connected to a DB.
>>>> either the Autocompletion window appears but displays the list of tables from the currently connected to database.<---In case the current FluidShell tab is connected to a DB.

In your test cases, "echo hello >", "declare >>": bash parser failed to parse the input and hence auto-completion handler set the default behavior to the value returned from the CLI_SHELL_LINE_INTERPRETER_IMPLICIT_BEHAVIOR shell variable (which likely is sql in your test environment, that's why you see a list of tables is displayed).
If you set this variable to:
   set CLI_SHELL_LINE_INTERPRETER_IMPLICIT_BEHAVIOR=shell
and then re-run your test cases, you should get a list of files displayed.

Anyway, these test cases probably need to be checked by the auto-completion handler before set the default behavior.
By the way, in bash, "declare >>" will not display anything.

>> because SQL statements can be involved in such cases. For examples: 'select * from table / | tee <tab>'.

This is not correct.  FluidShell does not support this syntax.  You can _not_ have an SQL statement in conjunction with a command on the same line.  So, you can indicate a SQL statement and then pipe the output.  If you want to do something like that, you need to do the following ...

select * from table
\go | tee <tab>

The SQL statement is on one line, then the commands with the pipeline is on a separate line.

>> >> because SQL statements can be involved in such cases. For examples: 'select * from table / | tee <tab>'.

>> This is not correct.  FluidShell does not support this syntax.  
>> You can _not_ have an SQL statement in conjunction with a command on the same line.
>> So, you can indicate a SQL statement and then pipe the output.  If you want to do something like that, you need to do the following ...
>>
>>   select * from table
>>   \go | tee <tab>
>>
>> The SQL statement is on one line, then the commands with the pipeline is on a separate line.

I knew the following pipeline won't execute in the current implementation of fluid shell:
   'select * from table / | tee file.log'
When I reviewed auto-completion code yesterday, I noticed issue #6593 was logged for supporting:
   'select * from table / | tee <tab>'
and auto-completion window is displayed after <tab> key is pressed in the current implementation.

I was wondering whether this was requested for supporting V1 shell syntax. When modifying auto-completion code (ShellAutocomplete.java), make sure code for supporting V1 shell fits V2 shell syntax.

>> In your test cases, "echo hello >", "declare >>": bash parser failed to parse the input and hence auto-completion handler set the default behavior to the value returned from the CLI_SHELL_LINE_INTERPRETER_IMPLICIT_BEHAVIOR shell variable (which likely is sql in your test environment, that's why you see a list of tables is displayed).
>> If you set this variable to:
>>   set CLI_SHELL_LINE_INTERPRETER_IMPLICIT_BEHAVIOR=shell
>> and then re-run your test cases, you should get a list of files displayed.

Yes, however in both cases one would mainly expect to get the Autocompletion for a list of files as the output would be redirected to the specified file and not the specified table.